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Preface 


The  purpose  of  this  study  was  to  develop  a  personal 
computer  (PC)  software  requirements  model  for  AFSC  system 
program  offices  (SPOs).  This  model  assist  SPOs  in  mating  PC 
software  requirements  to  specific  software  applications.  It 
was  necessary  in  view  of  the  wide  use  of  PCs  to  enhance  SPO 
productivity  and  the  lac)c  of  a  comprehensive  criteria  to 
assist  SPOs  in  selecting  PC  software  application  packages 
which  will  provide  the  most  efficient  and  effective  means  of 
automating  tasks  within  their  functional  departments. 

Personnel  from  the  various  functional  departments 
within  five  SPOs  represencing  each  of  Air  Force  System 
Command's  five  product  divisions  (one  each  from  Aeronautical 
Systems  Division  [ASD] ,  Electronic  Systems  Division  [ESD] , 
Human  Services  Division  [HSD] ,  Munitions  Systems  Division 
[MSD] ,  and  Space  Systems  Division  [SSD] )  were  surveyed  to 
aid  the  development  of  the  proposed  PC  software  requirements 
model.  Although  (due  to  the  small  sample  size)  applica¬ 
bility  to  other  similar  organizations  is  limited,  the 
proposed  model  may  prove  beneficial  in  improving  the  present 
AF-wide  software  acquisition  process  and  may  result  in  great 
cost  savings  and  improved  productivity. 

In  performing  this  research,  I  am  indebted  to  many  who 
provided  invaluable  assistance.  I  owe  special  thanks  to  my 


thesis  advisor,  Lt  Col  D.  J.  McBride  whose  patience, 
encouragement,  and  willing  assistance  were  truly  motiva¬ 
tional.  In  addition,  I  must  express  my  gratitude  to 
Dr  Charles  Fenno  who  provided  invaluable  assistance  and  many 
kind  words  of  inspiration.  I  also  would  like  to  thank  my 
parents  and  fiance^,  Denise,  for  their  never-ending  prayers 
and  reassurance.  And,  la'^tly,  I  must  give  all  the  praise 
and  glory  to  my  Lord  and  Saviour,  Jesus  Christ  to  whom 
without  him,  I  could  not  have  persevered  this  e  ndeavor . 

Derrick  M.  Richardson 
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Abstract 

This  research  effort  was  devised  to  discover  whether  the 
development  of  an  alternative  PC  software  requirements 
determination  model  for  system  program  offices  (SPOs)  within 
Air  Force  Systems  Command  (AFSC)  might  improve  their  current 
software  acquisition  process.  In  developing  this  model  an 
understanding  of  the  present  methods  used  to  define  personal 
computer  (PC)  software  requirements,  along  wirh  the  current 
procurement  methods  employed  were  examined.  The  model  is 
designed  to  match  SPO  mission  objectives  and  functions  with 
critical  office  tasks  necessary  to  accomplish  these  objec¬ 
tives  and  functions.  It  then  investigates/selects  those  PC 
software  products  which  will  best  support  the  office 
task(s).  Use  of  this  alternative  PC  software  requirements 
should  able  SPOs  to  better  define,  justify,  and  satisfy  PC 
software  requirements. 

Five  research  objectives  were  addressed  to  accomplish 
this  study: 

1.  Determination  of  the  effectiveness  of  currently 
available  PC  software  applications  used  to  support 
SPO  tasks. 

2.  Determination  of  the  current  processes  SPOs  use  to 
identify  PC  software  requirements. 

3.  Determination  of  the  methods  SPOs  currently  use  to 
acquire  PC  software  products. 

ix 


4.  Determination  of  the  ef  f  ec*^  iveness  of  present  PC 
software  requirements  identification  and  procurement 
practices . 

5.  Determination  of  whether  the  development  of  a 
tailored  PC  software  requirements  model  for  SPOs 
might  improve  the  PC  software  acquisition  process. 

The  primary  methodology  employed  consisted  of  a  29- 
question  survey  of  75  personnel  assigned  to  five  SPOs  (one 
from  each  of  the  five  product  divisions)  within  AFSC.  This 
survey  explored  the  PC  software  applications  currently  in 
use,  how  SPOs  determine  PC  software  requirements,  how 
effective  are  the  current  requirements  determination 
methods,  and  how  an  alternative  PC  software  requirements 
model  might  improve  the  current  procurement  process. 

The  Suggested  or  Alternative  Requirements  Determination 
Model  was  developed  from  the  literature  reviewed  on  infor¬ 
mation  systems  and  data  collected  from  the  survey.  The 
model  provides  a  comprehensive  methodology  for  assisting 
SPOs  in  determining  PC  software  requirements.  Better 
determination  of  PC  software  requirements  should  malie 
choosing  the  right  software  for  the  right  job  an  easier 
task,  thereby  resulting  in  enhanced  mission  effectiveness. 
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DEVELOPMENT  OF  A  PERSONAL  COMPUTER  (PC)  SOFTWARE 


REQUIREMENTS  MODEL  FOR  SYSTEM  PROGRAM  OFFICES 


I.  Introduction 


Overview 

This  chapter  defines  the  research  problem  by  first 
describing  the  current  method  of  personal  computer  (PC) 
software  acquisition  in  the  Air  Force  and  then  explaining 
the  basic  approach  used  to  explore  the  problem  of  deter¬ 
mining  PC  software  requirements  in  system  program  offices 
(SPOs) .  Specifically,  this  chapter  includes  a  problem 
overview,  specific  research  question,  basic  definitions, 
research  purpose  and  approach,  key  assumptions  and 
limitations,  research  objectives  and  investigative 
questions,  and  concludes  with  a  brief  overview  of  the 
remaining  chapters. 

Research  Problem  Overview 
Background 

The  number  of  PCs  in  organizations  has  been  steadily 
increasing  across  the  U.S.  for  two  primary  reasons.  First, 
the  rapid  advances  in  microcomputer  technology  have  consis- 
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tently  pushed  the  PC  cost/perf ormance  ratio  along  a  30  to  40 
percent  price  reduction  curve  each  year  and  are  expected  to 
continue  at  this  rate  well  into  the  1990s  (9:3-10).  Second, 
more  executives  are  beginning  to  realize  how  much  this 
technology  can  improve  their  office  productivity  and 
potentially  give  them  a  competitive  edge  over  their  rivals 
(64:98-103) . 

For  the  Department  of  Defense  (DoD) ,  functioning  in  an 
era  of  continued  manpower  cuts  (the  notion  of  "doing  more 
with  less")  and  increased  public  scrutiny  of  military 
management  practices,  these  tools  have  ta)cen  on  added 
significance  as  DoD  organizations  search  for  better  ways  to 
increase  office  efficiency  and  effectiveness  (79:89). 

Perhaps  nowhere  is  this  search  more  evident  than  in  SPOs, 
where  timely,  organized,  and  accurate  information  is 
essential  to  the  success  of  an  acquisition  program  (87). 

This  increasing  reliance  on  office  automation  malces  choosing 
the  right  software  for  the  right  job  an  increasingly 
important  endeavor.  To  meet  this  demand  for  increased 
productivity,  the  Air  Force  is  placing  greater  attention  on 
office  automation  through  the  acquisition  of  inexpensive 
PCs.  These  relatively  inexpensive,  yet  sophisticated 
management  tools  require  software  that  is  both  efficient  and 
effective.  In  other  words,  to  get  "the  most  bang  for  the 
buck"  from  these  PC  management  tools,  it  is  essential  that 
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adequate  resources  be  spent  to  define  software  and  hardware 
requirements  and  to  plan  the  implementation  of  such  systems. 
Lee  states  that  very  little  attention  has  been  devoted  to 
establishing  a  connection  between  the  availability  of  PC 
technology  and  how  it  should  be  used  by  professional  workers 
and  managers  (57:313).  However,  often  this  initial  invest¬ 
ment  in  planning  is  not  made  as  evidenced  by  a  recent  study 
of  office  management  practices.  This  study  suggests  two 
potential  hindrances  to  effective  office  automation: 

1.  Organizations,  in  their  haste  to  acquire  PC  systems 
to  aid  office  automation,  frequently  neglect  to  adequately 
define  the  purposes  for  which  the  systems  will  be  used. 

2.  Such  precipitous  PC  acquisitions,  coupled  with  a 
lack  of  user  involvement  (in  the  acquisition  process)  and 
inadequate  personnel  training,  have  greatly  contributed  to 
the  passive  acceptance  of  these  systems  by  the  intended 
users  (22:170-171;  57) . 

Although  the  acquisition  and  implementation  of  PC 
systems  have  (according  to  various  AFSC  program  managers) 
increased  office  efficiency  and  productivity  in  SPOs, 
improper  or  inadequate  planning  for  these  systems  has 
decreased  their  overall  cost  effectiveness.  Such  poor 
organizational  planning  in  the  form  of  limited  information 
management  systems,  inadequate  information  analysis,  poor 
systems  development  processes,  and  underestimated  system 
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operation  and  maintenance  costs  can  easily  translate  into 
increased  system  life  cycle  costs-  This  realization  was 
further  echoed  at  the  1988  Executive  Seminar  on  Communi¬ 
cations  and  Computers  in  Air  Force  Systems  Command  (AFSC) 
where  the  following  issues  were  raised  in  PC  systems 
acquisition : 

The  problem  stems  from  the  lack  of  a  cohesive 
framework  and  planning  roadmap  to  guide  Air  Force 
information  system  design,  acquisition,  and 
implementation.  The  key  factors  affecting  this 
lack  of  cohesion  are  the  technology  explos’'^’'.  the 
exponential  growth  in  user  requirements, 
ill-defined  requirements  and  technical  solutions, 
and  a  difficulty  in  focusing  programs  on  mission 
needs.  The  result  has  been  a  proliferation  of 
incompatible  stand-alone  systems,  mission  support 
deficiencies,  a  duplication  of  effort,  a  waste  of 
resources  and  a  loss  of  credibility  (90). 

This  problem  is  not  DoD  unique.  Lee  in  his  study  of  12 

organizations  ranging  from  small  businesses  to  Fortune  500 

companies,  found  that  merely  increasing  the  presence  of  PCs 

in  the  office  does  not  guarantee  they  will  be  used 

effectively  (57:313).  Young  agrees  and  estimates  between  20 

and  36  percent  of  all  PCs  end  up  being  abandoned  by  users 

due  to  ineffective  use  (99:100-114). 

In  an  effort  to  curtail  some  of  these  problems,  a  PC 

system  requirements  model  should  be  designed  to  provide  the 

"cohesive  framework"  and  "roadmap"  necessary  to  assist 

organizations  in  defining  PC  software  requirements. 

Currently,  the  Air  Force  has  two  publications  which  address 
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PC  requirements  determination:  AFR  700-26  (Acquisition  and 
Management  of  Small  Computers)  and  AFP  700-30  (How  to 
Determine  and  Justify  Information  Systems  Requirements  in  an 
Office  Environment) .  Both  publications  offer  organizations 
assistance  in  determining  PC  requirements  by  recommending 
procedures  for  system  development  and  user  involvement 
during  requirements  analysis.  However,  neither  advocates  a 
tailored  approach  (specifically  designing  the  PC  require¬ 
ments  analysis  to  fit  the  individual  organization)  to  PC 
requirements  determination.  A  tailored  approach  would  allow 
organizations  the  flexibility  to  match  PC  systems  to  their 
specific  organizational  needs.  Basically,  AFR  700-26 
describes  the  PC  systems  acquisition  process  (for  both 
hardware  and  software) ,  and  AFP  700-30  uses  a  top-down 
design  structure  to  give  organizations  a  way  to  identify 
potential  areas  for  automation.  Nevertheless,  neither 
publication  provides  guidance  in  determining  specific 
hardware  and  software  requirements.  Handy  recently 
developed  a  preliminary  model  which  maps  PC  software 
requirements  to  Air  Force  needs  (44).  This  study  focuses  on 
extending  the  model  specifically  for  system  program  offices 
(SPOs)  within  AFSC . 
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Specific  Problem 


With  the  abundance  of  PC  software  cools  on  the  market 
to  perform  a  multitude  of  tasks,  choosing  the  correct 
software  to  automate  selected  SPO  tasks  can  be  a  difficult 
proposition.  The  problem  is  there  are  no  comprehensive 
criteria  for  assisting  SPOs  in  deciding  which  software 
packages  to  choose  in  order  to  provide  the  most  efficient 
and  effective  automation  of  their  functional  departments. 
Thus,  the  research  question  becomes:  What  selection  process 
should  SPOs  use  to  acquire  the  best  possible  PC  software  to 
efficiently  and  effectively  automate  selected  office  tasks? 

Definitions 

Application  Programs  (or  Software)  -  Computer  programs 
used  to  perform  specific  user  tasks,  such  as  word 
processing,  database  management,  etc.  They  may  be 
general-purpose  or  specifically  designed  to  address  unique 
tasks  (30:6) . 

Requirement  -  A  need  for  a  new  or  improved  way  of 
capturing  or  processing  data,  producing  information, 
controlling  a  business  activity,  or  supporting  management. 

If  this  need  is  satisfied,  it  could  potentially  increase 
mission  success  and/or  decrease  mission  support  costs 
(88:66;  29:1) . 
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Requirements  Determination  -  The  process  of  using 
strategies  and  procedures  to  evaluate  management 
goals/objectives  and  behavior  characteristics  to  fulfill  a 
user  application  need.  It  involves  studying  the  current 
information  system  to  discover  how  it.  works  and  where 
improvements  can  be  made  (25:473-496;  88:66). 

Software  Product  -  Specifically  named  application 
programs  like  CONDOR,  WORDPERFECT  5.0,  MathCAD,  etc. 

Software  Type  -  Categories  in  which  software  products 
may  be  placed,  like  spreadsheets,  word  processors,  decision 
support  systems,  etc.  (44:7). 

Appendix  A  contains  a  more  comprehensive  list  of  terms 
used  in  this  study. 

Scope  of  Research  and  Method  of  Organization 
Justification 

SPOs,  along  with  other  Air  Force  organizations, 
currently  use  the  Small  Computer  Technical  Centers  (SCTCs) 
to  specify  and  process  PC  software  requirements.  These 
SCTCs,  in  addition  to  managing  the  software  libraries  for 
each  major  command,  also  provide  Government-owned/licensed 
software  to  authorized  users  upon  request  and  make  cata¬ 
logues  of  commercial  and  DoD  developed  software  products 
available  to  Air  Force  personnel  (30).  What  they  do  not  do, 
however,  is  match  office  PC  software  requirements  to  a 
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specific  software  application.  Consequently,  according  to 
interviews  with  various  SPO  directors  from  each  of  AFSC’s 
five  product  divisions  (Aeronautical  Systems  Division  [ASD] , 
Electronic  Systems  Division  [ESD] ,  Human  Services  Division 
[HSD] ,  Munitions  Systems  Division  [MSD] ,  and  Space  Systems 
Division  [SSD] )  many  SPO  organizations  have  acquired  a 
number  of  PC  software  programs  only  to  have  them  be  used 
improperly  or  not  at  all.  The  results  from  this  study 
should  prove  useful  in  improving  the  current  process  of 
mating  SPO  PC  software  requirements  to  specific  software 
applications . 

Research  Approach 

This  study  involved  a  survey  of  SPO  functional 
department  personnel.  One  SPO  from  each  of  the  five  product 
divisions  in  AFSC  was  selected  to  participate.  The  survey 
was  designed  to  provide  supporting  evidence  for  potential 
improvements  to  the  PC  software  acquisition  process. 

Key  Assumptions 

1.  All  SPOs  use  PCs  compatible  with  the  systems 
specified  in  the  Air  Force  Standard  Personal/Small 
Computer  Contract. 

2.  SPOs  surveyed  were  representative  of  all  SPOs. 

3.  Persons  surveyed  were  representative  of  all  SPO 
personnel . 
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Limitations 

1.  Only  one  SPO  from  each  AFSC  product  division  was 
surveyed . 

2.  Not  all  SPO  personnel  surveyed  know  how  their 
departments  acquire  PC  software  to  automate 
specific  office  tasks. 


Research  Objectives 

To  assist  the  development  of  a  PC  software  requirements 
model  for  SPOs,  the  following  research  objectives  were 
addressed : 

1.  Determination  of  the  effectiveness  of  currently 
available  software  applications  used  to  support  SPO 
tasks . 

2.  Determination  of  the  current  processes  SPOs  use  to 
identify  PC  software  requirements. 

3.  Determination  of  the  methods  SPOs  currently  use  to 
acquire  PC  software  products. 

4.  Determination  of  the  effectiveness  of  present  PC 
software  requirements  identification  and 
procurement  practices. 

5.  Determination  of  whether  the  development  of  a 
tailored  PC  software  requirements  model  for  SPOs 
might  improve  the  PC  software  acquisition  process. 


Investigative  Questions 

The  following  investigative  questions  were  addressed 
during  the  course  of  this  research  effort: 

1.  Who  are  the  users  of  PC  software  products? 

2.  a.  What  PC  software  products  are  SPOs  currently 

using? 

2.b.  How  often  are  these  products  used? 
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2. C.  How  satisfied  are  the  users  with  these  products? 

3.  Which  PC  software  products  are  the  most  critical 
for  SPOs? 

4.  Are  current  PC  software  products  being  used  for 
their  intended  purposes? 

5.  Are  personally-owned  PC  software  products  used  to 
accomplish  office  tasks?  Which  ones,  and  why  are 
they  used? 

6.  Is  there  a  departmental  policy  establishing  a 
process  or  method  for  determining  PC  software 
requirements? 

7.  What  guidance  do  SPOs  receive  when  defining  PC 
software  requirements? 

8.  Who  defines  SPO  PC  software  requirements? 

9.  What  acquisition  methods  do  SPOs  use  when 
purchasing  PC  software? 

10.  How  effective  and  efficient  are  SPO  PC  software 
acquisition  methods  in  providing  the  correct  or 
requested  software? 

11.  Are  there  alternative  methods  or  improvements  which 
could  be  made  to  the  current  PC  software 
procurement  process? 


Thesis  Organization 

The  remainder  of  this  study  is  structured  towards 
answering  the  investigative  questions  posed  above.  Chapter 
II  contains  a  review  of  the  literature  on  PC  requirements 
analysis  and  a  brief  description  of  the  current  PC 
requirements  analysis  models  (for  both  hardware  and 
software) .  The  specific  methodology  used  in  this  research 
effort  is  detailed  in  Chapter  III.  It  describes  how  the 
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survey  instrument  was  constructed  and  how  the  data  gathered 
was  analyzed.  In  Chapter  IV,  Results  and  Discussion,  the 
data  gathered  from  the  questionnaire  was  used  to  answer  the 
investigative  questions  posed  in  this  chapter  and  to  develop 
an  alternative  PC  software  requirements  model.  Finally, 
Chapter  V,  Conclusions  and  Recommendations,  summarizes  the 
research  study  explaining  the  rationale  for  selecting  the 
proposed  SPO  PC  requirements  model  over  other  models.  It 
also  provides  recommended  areas  for  further  research. 
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II.  Literature  Review 


Introduction 

Office  automation  can  be  broadly  interpreted  as  the  use 
of  computer  technology  to  perform  various  knowledge  tasks. 
But  it  specifically  represents  the  modern  method  of  handling 
business  documents  and  person-to-person  communications.  It 
consists  of  capital  investments  in  electronic  office 
equipment  (like  PCs,  telefax  machines,  etc.)  connected  to  a 
communication  network  which  forms  an  integrated,  multi¬ 
functional,  electronic  office  within  an  organization  (95:4). 
Although  much  has  been  written  regarding  the  implementation 
and  use  of  office  automation  .systems,  the  area  of  PC  soft¬ 
ware  requirements  analysis  to  support  office  tasks  has 
received  little  attention.  Various  office  automation 
topics,  nonetheless,  have  supplied  invaluable  information 
which  is  deemed  pertinent  to  PC  software  requirements 
analysis.  This  research  examined  some  of  the  related 
aspects  of  office  automation  such  as  end-user  computing, 
personal  computing,  and  considerations  for  PC-based  software 
applications  in  office  automation  development.  In  addition, 
current  PC  publications  were  researched  for  guidelines  to 
buying  PC  software,  and  Appendix  B  gives  ratings  of  various 
PC  software  applications 
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for  the  office  environment.  The  findings  of  this  review 
follow. 

End-User  Computing 

As  the  decline  in  U.S.  productivity  becomes  more 
salient,  there  is  an  increasing  focus  on  innovations  for 
business  organizations  (16:1).  This  quest  for  continued 
productivity  is  echoed  in  such  works  as  The  Change  Masters 
by  Ranter  (1983)  ,  In  Search  of  Excellence  by  Peters  and 
Waterman  (1982),  and  the  Age  of  Discontinuity  by  Peter 
Drucker  (1978).  Drucker  understood  the  importance  of 
knowledge  work  in  promoting  an  increase  in  office 
productivity.  He  said: 

To  make  knowledge  work  more  productive  will  be  the 
great  management  task  of  this  century,  just  as  to 
make  manual  work  [more]  productive  was  the  great 
management  task  of  the  last  century  (33:290). 

Knowledge  work  includes  tasks  which  involve  thinking, 

processing  information,  formulating  analyses,  making 

recommendations,  and  developing  information  systems 

(25:409).  In  an  effort  to  increase  productivity,  knowledge 

workers  increasingly  make  use  of  information  technology, 

like  intelligent  workstations,  information  retrieval, 

communications,  and  decision  support  systems  (16:1).  The 

effective  use  of  office  auto’«=»tion  offers  management  some 

unique  opportunities  for  addressing  complex  productivity 

issues  facing  today's  office  environment  (95:1).  An 
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innovative  use  of  this  information  technology  is  end-user 
computing.  Leitheiser  and  Wetherbe  define  end-user 
computing  as  the  "use  and/or  development  of  information 
systems  by  the  principle  users  of  the  system’s  outputs  or  by 
their  [support]  staffs"  (96:3).  End-user  computing  gives 
users  the  capability  to  have  direct  control  of  their 
computing  needs  and  is  steadily  increasing  in  importance  for 
organizations.  It  is  expected  to  be  the  fastest  growing 
area  of  computer  use  for  the  coming  decade.  In  the  very 
near  future,  it  is  estimated  that  50-100  percent  of  the 
computer  processing  power  available  within  organizations  (as 
compared  to  15-20  percent  for  traditional  applications)  will 
be  used  for  end-user  computing  (83:776).  This  trend  is 
understandable  when  the  advantages  of  end-user  computing  are 
considered.  These  advantages  include: 

1.  Better  and  more  timely  access  to 
information,  which  means: 

2.  Improved  decision-making, 

3.  Improved  user  control  and  acceptance  of 
information  system  implementation,  and 

4.  Lower  system  development  costs.  (16:1) 

In  addition,  Leitheiser  and  Wetherbe  noted  eight 
reasons  why  users  choose  to  do  their  own  computing: 

1.  Users  have  more  control  of  information  system  use 
and  development. 

2.  Lead  times  for  development  requests  are  shorter. 
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3.  User  developed  information  systems  better  meet  user 
needs . 

4.  Services  are  not  available  from  MIS  departments. 

5.  Users  perceive  MIS  departments  are  not  concerned 
about  their  needs. 

6.  Small  applications  are  not  well-suited  to  MIS 
department  procedures. 

7.  Users  are  motivated  by  a  vested  interest  to  learn 
about  computing. 

8.  Users  have  more  flexibility. 

9.  Development  costs  are  lower  (96:3-10). 

However,  Davis  and  Olson  are  quick  to  point  out  the 

potential  risks  of  end-user  computing.  These  disadvantages 
are:  (1)  the  risk  of  eliminating  the  separate  functions  of 

the  user  and  the  analyst  (as  an  independent  reviewer)  in 
building  and  using  support  systems  that  meet  organizational 
objectives,  (2)  the  limited  ability  of  the  user  to  identify 
correct  and  complete  requirements  for  an  application,  (3) 
potential  for  unreliable  information  systems  due  to  a  lack 
of  quality  assurance  procedures,  (4)  the  risk  of  developing 
incompatible  systems  as  a  result  of  non-standard  interfaces 
between  organizational  departments,  and  (5)  the  over-use  of 
private  information  systems  (which  may  encourage  information 
hiding)  when  organizational  systems  may  be  more  appropriate 
(25:430-431).  In  view  of  the  advantages  and  disadvantages 
delineated  above,  the  key  issue  for  managing  end-user 
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computing  is  to  maximize  its  benefits  while  minimizing  its 
risks  (16:2) . 

Organizationally,  there  are  four  important  issues  in 
the  context  of  end-user  computing: 

1.  Policy  and  procedures  for  microcomputer  acquisition 
and  use, 

2.  End-user  software  support, 

3.  Organization  of  the  information  center,  and 

4.  End-user  satisfaction  (25:650). 

Microcomputer  Acquisition  and  Use.  Parallel  with  the 
trend  toward  end-user  computing  is  a  significant  shift 
towards  decentralization  in  the  use  of  information  system 
resources.  Although,  theoretically,  the  organization  of 
end-user  computing  can  be  either  centralized  or  decen¬ 
tralized,  the  use  of  microcomputers  (or  PCs)  has  fostered 
increased  decentralization.  Their  relatively  low  cost  makes 
it  easy  for  departments  or  individuals  to  acquire  ther, 
within  their  budget  without  oversight  from  upper-level 
management.  These  systems  bring  instant  technology  and 
promote  user  innovation,  but  (according  to  Davis  and  Olson) 
they  can  also  pose  several  problems: 

1.  Acquired  microcomputers  may  be  incompatible.  This 
may  not  be  important  at  first,  but  with  expanded 
use,  there  is  a  need  to  transfer  data  and  software. 

2.  The  microcomputers  may  need  to  access  data  from  a 
mainframe  computer  which  requires  special  software 
and  may  introduce  additional  data  control  problems. 
An  assortment  of  microcomputers  makes  this  process 
more  difficult. 
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3.  A  variety  of  vendors  for  hardware  and  software 
complicates  maintenance. 

4.  Difficulties  and  inefficiencies  in  training  are 
magnified  when  there  is  an  assortment  of 
microcomputers  and  software  (25:650-651). 

As  a  result  of  these  problems,  many  organizations  have 

established  policies  for  microcomputers  setting  limits  on 

the  number  of  hardware,  software,  and  vendor  options.  In 

turn,  these  options  are  normally  supported  by  the  training, 

consulting,  and  maintenance  staffs  of  the  information  or 

computer  center  (25:651). 

End-User  Software  Support.  One  area  of  great  concern 
similar  to  microcomputer  acquisition,  is  the  availability  of 
central  support  for  software  (especially  software  other  than 
the  standard  packages  defined  in  the  procurement  contract) . 
Because  users  may  develop  thei-r  own  software,  procure 
software  applications  on  their  own,  or  contract  with 
information  systems  support  staffs  to  procure  software 
packages,  many  authorities  believe  this  makes  adherence  to 
rigid  system  development  life  cycle  procedures  virtually 
impossible.  In  particular,  continued  maintenance  of  these 
software  packages  poses  significant  problems.  Persons 
responsible  for  developing  or  procuring  the  software  may 
relocate  to  other  positions  or  organizations,  leaving  the 
software  without  knowledgeable  user  support  personnel. 
Moreover,  vendors  may  provide  upgrades  or  changes  to  the 
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software  requiring  expertise  to  install.  Factors  such  as 
these  suggest  the  need  for  organizational  policy  delineating 
clearly  defined  roles  and  responsibilities  for  end-users  and 
information  centers  (25:651),  as  well  as  standards  for 
procuring  hardware  and  software  (49:143),  One  method, 
expounded  by  Leitheiser  and  Wetherbe,  is  to  define  classes 
or  levels  of  provided  software  support  (see  Table  1) 
[59:339-342].  Davis  and  Olson  aptly  describe  three 
advantages  of  such  a  policy: 

1.  Users  have  the  flexibility  to  experiment  with 
undocumented  software  paclcages  or  write 
undocumented  software  programs,  but  they  Icnow  up¬ 
front  whether  these  experiments  will  be  supported. 

2.  If  users  want  complete  support,  they  must  negotiate 
the  formal  organizational  review  and  approval 
process . 

3.  Users  may  buy  software  which,  initially,  may  not 
need  support,  but  if  (or  when)  it  is  needed,  they 
may  have  to  wait  and  negotiate  that  support 
(25:652) . 

Information  Centers.  Approximately  80  percent  of  U.S. 
business  organizations  have  information  centers  (36:31). 

The  term  was  coined  by  IBM  in  1976  (98:32),  and  the  concept 
is  based  on  providing  end-users  with  direct,  ready  access  to 
computation,  consultation,  and  information  processing 
resources  through  a  central  facility.  These  resources  allow 
end-users  to  perform  their  own  analysis,  develop  systems, 
access  data,  etc.  Specific  traditional  support  includes  the 
following : 


18 


Table  1.  Classes  of  Software  Support  (25:651) 


Class  of  Support 
Complete  Support 


Negotiated 

Support 


Support  Will  Not 
Be  Provided 


Explanation 

Software  developed  and 
documented  by  information 
systems  staff. 

Software  acquired  from  outside 
vendors  but  reviewed  and 
approved  by  information  systems 
staff  as  having  adequate 
documentation  and  other  features 
for  maintainability. 

User-developed  systems  that  meet 
standards  for  documentation  and 
have  been  reviewed  and  approved 
by  information  systems  staff. 

Software  acquired  from  outside 
vendors  or  developed  by  users 
that  is  documented  but  has  not 
been  reviewed  and  approved  for 
complete  maintenance.  Support 
must  be  requested  and 
negotiated. 

Software  without  documentation. 
This  may  also  include  software 
written  in  languages  that  are 
not  supported  by  the  installa¬ 
tion’s  information  system  staff. 


1.  Technical  assistance  in  writing 
instructions  in  a  very  high  level 
language . 

2.  Education  in  the  use  of  high-level 
languages  and  development  tools. 

3.  Assistance  in  accessing  data  from  a  main 
computer . 

4.  Assistance  in  debugging  programs. 
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5.  Access  to  reference  material  on 
facilities,  databases,  etc. 

6.  Administration  support  for  various 
computing  procedures.  (25:428) 

In  addition  to  the  support  functions  listed  above,  today's 

modern  information  centers  provide  further  assistance  to 

end-users  in  the  following  areas: 

1.  Recommending  personal  computer  purchases. 

2.  Determining  appropriate  software  packages. 

3.  Establishing  standards  for  application  development. 

4.  Determining  the  best  tools  to  accomplish  a  project. 

5.  Training  end-users  to  define  information  require¬ 
ments  and  how  to  use  various  software  tools. 

6.  Coordinating  and  storing  individual  applications 
and  data  bases  to  eliminate  redundant  efforts 
(98:34) . 

Although  information  center  personnel  usually  act  as 
teachers  and  consultants  to  users,  they  do  not  develop  end- 
user  applications.  Instead,  they  provide  users  with  the 
knowledge  and  skills  to  develop  their  own  applications 
(98:32).  Thus,  information  centers  may  have  small  staffs, 
but  it  is  vital  they  have  a  diverse  set  and  knowledge  of 
hardware  and  software  tools  (including  mainframe  and 
personal  computers),  and  computing  techniques,  tactics,  and 
strategies  if  they  are  to  remain  successful  (72:71-72). 

End-User  Satisfaction.  End-user  computing  is  important 
to  the  development  of  a  PC  software  requirements  model 
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because  identifying  these  requirements  may  entail  end-user 
identification  and  selection  of  system  configuration  and 
operation  (44:24).  Consequently,  an  examination  of  end-user 
computing  satisfaction  may  be  beneficial  in  determining  why 
certain  PC  systems  and  configurations  are  judged  better  than 
others.  Doll  and  Torkzadek  compared  traditional  and  end- 
user  computing  to  discover  a  way  to  measure  end-user 
'computing  satisfaction.  They  discovered  five  components  of 
end-user  system  satisfaction.  They  are: 

1.  Content, 

2.  Accuracy, 

3.  Format, 

4.  Ease  of  Use,  and 

5.  Timeliness  of  information  (32:270-272). 

In  a  study  of  12  business  organizations,  Dennis  Lee 
discovered  some  very  positive  trends  in  end-user  computing 
satisfaction.  He  found  users  were,  generally,  satisfied 
with  their  PCs  and  sought  other  users  as  key  sources  for 
help  in  application  development  and  in  determining  system 
configurations.  He  also  examined  the  implementation  of  PC- 
based  systems  in  two  commercial  product  divisions  to  find 
out  whether  better  system  use  resulted  from  increased  user 
planning.  Although  both  divisions  were  satisfied,  the 
division  employing  greater  user  planning  was  judged  much 
more  productive  (57:321-322). 
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Personal  Computing 

One  of  the  main  problems  facing  office  management 
departments  pursuing  increased  automation  is  ascertaining 
the  proper  role  (requirements  analysis)  of  personal 
computers  in  the  organization  to  ensure  end-users  needs  are 
met  (58:1).  In  fact,  a  recent  study  of  12  organizations  on 
PC  usage  (ranging  from  small  businesses  to  Fortune  500 
companies)  revealed  two  key  findings.  One  is  that  the  most 
important  reason  for  using  PCs  is  to  assist  various 
professional  (knowledge)  work  tasks.  The  other  is  the 
challenge  for  management  to  find  the  most  effective  and 
efficient  way  to  integrate  this  technology  into  the 
workplace  (57:324). 

One  way  to  do  this  is  to  employ  a  concept  called 
personal  computing.  Personal  computing  refers  to  "the  use 
of  computer  resources  by  an  individual  to  carry  out  his  or 
her  job"  (58:1).  The  idea  is  to  give  the  individual 
managers  the  flexibility  to  use  the  PC  in  the  manner  which 
best  supports  his/her  job.  This  decentralization  makes  the 
manager  responsible  for  using  and  manipulating  the  right 
data  to  achieve  the  desired  management  result(s)  [58:11]. 
However,  the  difficult  task  becomes:  1)  what  data  to  select 
and  2)  what  is  the  best  way  to  manipulate  the  data.  This 
research  concentrates  on  the  latter  by  trying  to  help  the 
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SPO  manager  select  the  most  appropriate  PC  software  tools  to 
help  him/her  achieve  cheir  management  objectives. 

Centralized  vs  Decentralized  Control.  Because  personal 
computing  systems  are  generally  not  expected  to  be  used  by 
an  entire  organization,  either  centralized  or  decentralized 
control  practices  may  be  used.  In  fact,  the  original 
concept  of  the  information  center  assumed  centralized 
facilities  would  be  used  to  provide  the  necessary  tools  for 
individuals  to  develop  their  own  computing  applications. 
However,  the  trend  in  recent  years  has  been  to  employ  a 
decentralized  structure — thus  the  popular  connection  of 
personal  computing  with  personal  computers.  Lehman  believes 
the  reason  for  this  trend  of  decentralization  is  two-fold. 
One  is  economic  because  it  is  deemed  more  cost  effective  to 
have  each  manager  or  department  be  responsible  for  acquiring 
and  maintaining  their  respective  personal  computing  system. 
The  rationale  here  is  that  because  information  is  primarily 
used  by  a  single  individual,  any  problems  encountered  with 
quality  or  integrity  have  limited  impact  upon  the  whole 
organization.  This  means  large  investments  in  reliable 
hardware  and  software  and  in  security  and  control  measures 
(indicative  of  organizational  computing  systems)  need  not  be 
made  for  personal  computing  systems.  The  second  part  is 
political  in  that  if  an  organization  decides  on  a 
centralized  structure  for  their  personal  computing 
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operations,  it  implies  submission  by  the  individual  managers 
to  controls  characteristic  of  organizational  computing 
systems  (58 : 6-7 ) . 

Lehman  aptly  points  out  that  the  philosophy  behind 
decentralized  control  and  decision-making  (accompanying 
recent  trends  in  organizational  structure  development)  is 
that  middle-level  managers  should  be  held  accountable  for 
the  results  of  their  operation.  Affording  them  the 
opportunity  to  achieve  those  results  in  whatever  manner  best 
fits  their  operation  will  produce  better  decisions  and 
higher  motivation  (58:5).  Robert  Anthony  also  supports  this 
view,  stating  that  most  organizations  have  discovered 
decentralization  of  management  decision-making  leads  to 
better  decisions  and  increased  productivity  (given  proper 
control  and  motivation)  over  that  of  centralization  (3).  It 
only  makes  sense  (given  the  potential  for  misuse  will  have 
little  impact  upon  the  entire  organization)  to  give  the 
manager  responsible  for  the  results  the  authority  over  how 
best  to  achieve  those  results. 

Scope  of  Responsibility.  Just  because  an  organization 
chooses  to  use  personal  computing  systems  does  not 
necessarily  eliminate  the  need  for  support  personnel  like 
system  analysts  and  data  processing  specialists  in  personal 
computing  projects.  It  is  highly  unlikely  that  individual 
managers  (as  a  whole)  will  have  the  necessary  technical 
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skills  to  select  hardware  and  software  or  to  develop  and 
implement  complex  applications.  They  will  still  require 
technical  advice  to  review  requirements  and  proposed 
solutions  and  technical  assistance  to  implement  and  maintain 
the  system  (58:11). 

However,  there  is  a  change  in  the  level  of  responsi¬ 
bility.  In  personal  computing,  it  is  the  owner  of  the 
system  who  is  accountable  for  the  results  and  any  problems 
which  may  arise  from  the  use  of  that  system — the  MIS 
department  is  no  longer  responsible.  Lehman  summarizes 
this  difference  stating: 

If  the  equipment  is  not  suitable  for  the  task,  the 
manager  who  owns  the  [personal  computing]  system 
is  responsib?  .  not  the  MIS  department.  If  the 
system  produces  wrong  results,  the  manager  who 
owns  the  system  is  responsible,  not  the  MIS 
department.  If,  due  to  carelessness  about  backup, 
a  year's  worth  of  data  is  lost  and  the  department 
suffers  severe  financial  problems,  the  manager  who 
owns  the  system  is  responsible,  not  the  MIS 
department.  (58:12) 

Of  course,  no  one  wants  these  types  of  things  to  happen,  but 
the  risk  of  such  is  inherent  when  using  a  personal  computing 
system.  The  key  to  avoiding  these  kinds  of  problems  is  to 
ensure  the  MIS  department's  role  is  shifted  to  one  of 
education  (58:12).  By  organization-level  management 
stressing  the  need  for  individual  managers  (who  use  personal 
computing  systems)  to  seek  educational  assistance  from  the 
MIS  department  during  the  early  stages  of  system/application 


25 


development  and  implementation,  these  problems  may  be 
prevented . 

Considerations  for  PC-Based  Software  Applications  in  Office 
Automation  Development 

Defining  Software  Requirements.  Although  there  seems 
to  be  very  little  information  specifically  addressing  the 
process  of  defining  PC  software  requirements,  there  is 
information  addressing  information  system  requirements 
determination  which  can  be  applied  to  software.  The 
discussion  which  follows  highlights  that  information  which 
is  deemed  most  applicable  to  PC  software  requirements 
determination.  Presented  first  is  the  support  rationale  for 
software  requirements  determination,  followed  by  strategies 
for  consideration.  In  addition,  Appendix  C  provides  a  brief 
overview  of  some  of  the  more  widely  known  methodologies  used 
to  determine  information  system  requirements.  As  previously 
defined  in  Chapter  I,  requirements  determination  is  the 
process  of  using  strategies  and  procedures  to  evaluate 
management  goals/objectives  and  behavior  characteristics  to 
fulfill  a  user  application  need  (25:473-496). 

Support  Rationale.  The  requirements  phase  of  the 
software  life  cycle  precedes  the  design  of  the  software.  It 
includes  an  analysis  of  the  users'  needs  along  with  a 
specification  of  both  the  functional  and  non-functional 
requirements  (i.e.,  cost  of  the  software,  compatibility  with 
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the  present  hardware/software  configuration,  etc.)  of  the 
system  software.  To  carry  out  these  activities,  the  analyst 
must  have  a  clear  understanding  of  the  environment  in  which 
the  software  will  function  and  its  intended  purpose.  The 
focus  of  requirements  determination  should  be  on  what  you 
want  the  software  to  do,  as  opposed  to  how  you  want  it  done 
(13:82-83).  Because  quite  often  the  benefits  of  various 
software  applications  are  not  fully  realized,  an  effective 
requirements  determination  analysis  is  vital  to  assist 
organizations  in  fulfilling  their  automation  needs  (72:74). 
The  importance  of  requirements  analysis  was  reiterated  by 
the  DoD ' s  Defense  Science  Board  which  said,  "The  toughest 
part  of  the  problem  for  software  [selection  and  design]  is 
defining  the  exact  requirements"  (70:72).  AFP  700-30 
describes  reasons  for  the  limited  effectiveness  of 
information  technology--which  are  also  applicable  to 
application  software.  The  reasons  given  are  listed  below: 

1.  Many  times  information  technology  is  acquired 
without  establishing  clear  objectives  for  having 
it.  The  technology  will  most  liltely  yield  limited 
results  when  it  is  procured  without  first 
identifying  clear  objectives. 

2.  Poor,  previously  e:itablished,  procedures  are  not 
streamlined  prior  to  implementing  new  information 
technology.  Thus,  these  poor  procedures  are  done 
better,  but  still  very  inefficiently. 

3.  Because  there  is  no  easy  methodology  for 
requirements  determination,  many  managers  believe 
the  analysis  is  too  complicated.  As  a  result,  some 
managers  do  not  even  consider  the  possibility  of 
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using  information  technology  to  improve  their 
office  productivity. 

4.  Many  managers  who  are  aware  of  the  various 
information  technologies  and  could  take  advantage 
of  them,  do  not  because  they  have  difficulty 
justifying  their  requirements.  Consequently,  if  a 
requirement  is  not  justified,  it  must  not  be  valid. 

5.  Some  managers  are  too  quick  to  find  the  technical 
solution  before  they  fully  understand  the 
requirements.  This  tendency  "to  attempt  problem 
solution  before  problem  definition"  is  becoming 
more  prevalent  in  the  information  technology  world 
(29:1-3) . 

Requirements  Determination  Strategies. 

Undoubtedly,  requirements  determination  is  essential  to 
selecting  the  appropriate  software  application.  However, 
there  are  obstacles  to  performing  requirements  determination 
analysis.  Davis  says  there  are  four  major  reasons  it  is 
difficult  to  specify  a  complete  set  of  requirements.  They 
are  as  follows: 

1.  The  constraints  on  humans  as  information 
processors  and  problem  solvers.  [As 
information  processors,  humans  have 
limitations  in  terms  of  their  memory 
capacity,  are  biased  in  their  selection 
and  use  of  data,  and  use  bounded 
rationality  when  making  decisions.] 

2.  The  variety  and  complexity  of  information 
requirements . 

3.  The  complex  patterns  of  interaction  among 
users  and  analysts  in  defining 
requirements . 

4.  Unwillingness  of  some  users  to  provide 
requirements  (for  political  or  behavioral 
reasons).  (24:4-9) 
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The  difficulties  delineated  above  suggest  the  need  for 
several  general  strategies  of  requirements  determination. 
Selecting  the  appropriate  strategy  should  be  based  on  the 
contingencies  which  apply  to  a  specific  case.  The 
requirements  determination  strategy  is  defined  by  Davis  as 
"the  general  approach  to  obtaining  requirements"  (24:4). 

Davis  describes  four  strategies  for  information 
requirements  determination: 

1.  Asking  directly, 

2.  Deriving  from  an  existing  information 
system, 

3.  Synthesizing  from  characteristics  of  the 
utilizing  system,  and 

4.  Discovering  from  experimentation  with  an 
evolving  information  system.  (24:12) 

The  first  three  strategies  are  not  only  applicable  to 
determining  organizational  information  requirements,  but 
software  applications  as  well.  (The  fourth  strategy  is 
deemed  applicable  to  a  lesser  extent.)  Davis  further  points 
out  that  these  strategies  need  not  be  used  independently 

X 

(24:12).  In  fact,  a  1977  study  by  Munro  and  Davis  found 
analysts  and  users  preferred  a  mixed  strategy  to  define 
their  information  requirements  (68:55-67).  Appendix  C 
provides  a  brief  discussion  of  these  four  strategies. 

Selecting  a  Requirements  Determination  Strategy. 
Selecting  a  strategy  for  determining  information  require¬ 
ments  is  contingent  upon  the  environment  in  which  the 
requirements  determination  process  is  conducted.  The 
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approach  to  selecting  an  appropriate  strategy  involves 
determining  the  level  of  uncertainty  in  the  requirements 
determination  process  and  consists  of  five  basic  steps. 

These  steps  represent  a  series  of  uncertainty  eva''uations  to 
establish  a  basis  for  selection  (24:19-24).  The  steps  are 
summarized  by  Davis  in  Table  2.  However,  again,  the  analyst 
need  not  choose  one  of  these  methods  exclusively.  He/She 
may  decide  a  combination  of  strategies  is  most  appropriate 
for  determining  requirements  (25:497). 

Requirements  Determination  Methodologies .  This  section 
discusses  some  of  the  more  prevalent  information  require¬ 
ments  determination  methodologies  used  in  today's  office 
environment.  Although  every  methodology  has  its  own  unique 
features,  the  one  thing  they  all  have  in  common  is  fact¬ 
finding.  It  is  essential  for  the  analyst  to  acquire  all 
pertinent  facts  about  the  system/application  requirements  as 
quickly  and  as  accurately  as  possible.  These  facts  should 
tell  the  analyst  "why"  and  "how"  certain  activities  are 
performed  and  "what"  data  is  used  in  performing  these  tasks 
(88:73-85).  Timing,  frequency,  and  volume  of  activities  are 
also  important  data  to  gather  (88:68-70).  Used  properly, 
the  four  fact-finding  methods  of  interview,  questionnaire, 
on-site  records  review,  and  direct  observation  will  furnish 
this  necessary  information  (88:86). 
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Table  2.  Steps  in  Selecting  a  Strategy  and  Methods 
for  Determining  Information  Requirements  (24:20) 


1.  Identify  those  characteristics  of  the  four 
elements  in  the  development  process  that  affect 
uncertainty  in  the  determination  of  information 
requirements : 

■  Utilizing  system 

■  Information  system  or  application 

■  Users 

■  Analysis 

2.  Evaluate  the  effect  of  the  characteristics  of  the 
four  elements  in  the  development  process  on  three 
process  uncertainties: 

■  Existence  and  availability  of  a  set  of  usable 
requirements 

■  Ability  of  users  to  specify  requirements 

■  Ability  of  analysis  to  elicit  and  evaluate 
requirements 

3.  Evaluate  the  combined  effect  of  the  process 
uncertainties  on  overall  requirements  uncertainty. 

4.  Select  a  primary  strategy  for  requirements 

determination  based  on  the  overall  requirements 
and  level  of  uncertainty. 

Uncertainty  Strategy 

Low  Asking  directly 

T  Deriving  from  an  existing  system 

Synthesis  from  characteristics  of 
^  utilizing  system 

High  Discovering  from  experimentation 

5.  Select  one  or  more  methods  from  the  set  of  methods 
to  implement  the  primary  strategy. 


In  selecting  a  methodology,  it  is  also  important  to 
recognize  that  methodologies  vary  in  the  amount  of  structure 
they  provide.  Some  may  provide  a  good  conceptual  structure, 
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but  furnish  very  little  process  and  documentation  structure; 
others  may  supply  detailed  structure  for  all  tasks.  The 
degree  of  structure  importance  depends  on  the  situation. 

For  example,  analysts  and  users  with  little  experience  and 
know-how  may  want  a  great  deal  of  structure.  On  the  other 
hand,  experienced  analysts  and  users  who  are  familiar  with 
the  application  domain,  may  find  a  detailed  structure  a 
frustrating  road  block  (25:479). 

According  to  Davis,  a  methodology  for  requirements 
determination  should  be  able  to  accomplish  the  following: 

1.  Assist  the  analyst  in  formulating  the  problem 
space . 

2.  Assist  in  searching  efficiently  within  the  problem 
space  by  aiding  requirements  discovery  and  in 
overcoming  short-term  memory  limitations  in  human 
information  processing. 

3.  Assist  in  overcoming  biasing  factors  such  as 
recency,  concreteness,  small  sample  sizes,  and 
valuing  unused  data. 

4.  Aid  in  overcoming  user  or  analyst  prejudices,  lack 
of  training,  customs,  and  attitudes. 

5.  Provide  assurance  that  requirements  are  complete 
and  accurate  (25:479). 

Appendix  D  contains  descriptions  of  some  of  the  more  widely 
recognized  requirements  determination  methodologies  which 
adhere  to  the  above  criteria.  They  are  useful  in  assisting 
organizations  to  design  their  own  requirements  determination 
methodology . 
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Deciding  Which  Tasks  to  Automate.  The  dilemma  of 


deciding  which  tasks  to  automate  may  sometimes  be  as 
difficult  a  proposition  as  selecting  the  best  strategy/- 
methodology  for  defining  requirements  (55:8).  This  decision 
is  very  important  since — due  primarily  to  time  and  funding 
constraints — it  is  virtually  impossible  to  automate  every 
office  task.  Consequently,  managers  must  not  only  define 
but  prioritize  those  tasks  most  coveted  for  automation. 

Kumar  and  Welke  identified  two  factors  which  can  signifi¬ 
cantly  alter  the  task  selection  process.  These  factors  are 
viewpoint  differences  between  the  system  designers  and  the 
end-users .  Kumar  and  Welke  were  able  to  show  that  during 
information  system  development,  system  designers  pay  more 
attention  to  technical  and  economic  values  over  socio¬ 
political-psychological  values  like  user  satisfaction.  The 
researchers  believed  this  outcome  was  a  result  of  the 
organization's  reward  structure  being  tied  to  quantifiable 
economic  and  technical  criteria  (like  cost,  schedule,  and 
performance).  From  management's  perspective,  economic  and 
technical  values  are  directly  measurable,  whereas  user 
satisfaction  values  are  not  (55:8-10).  Thus,  depending  on 
the  organization's  or  department's  perspective,  the  priority 
ranking  of  different  tasks  for  automation  may  vary  a  great 
deal  from  one  department  to  another. 
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Managing  Requirements  Review  and  Selection.  Before  any 
requirement  is  implemented,  someone  or  some  group  of  people 
must  decide  whether  it  should  and  can  be  implemented.  This 
decision  to  accept  or  reject  a  request  can  be  made  in  a 
-umber  of  ways  bv  various  members  of  the  organizati^- .  f^ne 
of  the  more  common  ways  to  review  and  select  a  requirement 
for  implementation  is  by  committee.  Lucas  examined  three 
committee  types  for  this  purpose:  1)  information  systems 
committees ,  2)  user-group  committees ,  and  3)  steering 

committees.  Some  organizations  decide  a  committee  of 
managers  and  analysts  from  within  their  information  systems 
department  should  be  responsible  for  reviewing  and  selecting 
requirements  for  implementation,  hence  the  information 
systems  committee.  It  works  well  when  there  are  many 
requests  for  routine  applications  or  maintenance  (upgrades, 
debugging,  etc.)  on  existing  products.  Other  organizations 
choose  to  allow  the  actual  users  to  define  and  select 
requirements  for  implementation;  they  are  user-group 
committees.  In  this  way,  departments  form  their  own 
review/selection  committees.  However,  this  process  can  mean 
wasted  resources  due  to  the  lack  of  coordination  with  other 
organizational  departments.  Steering  committees  are 
primarily  composed  of  key  managers  from  the  various 
organizational  departments,  along  with  members  of  the 
information  systems  group.  These  individuals  have  the 
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responsibility  and  authority  to  decide  which  requirements 
are  most  important  to  achieve  mission  objectives  and  goals 
(88:47-49).  This  method  appears  to  be  the  best  of  the  three 
since  it  approaches  information  requirements  review/ - 
selection  as  a  management  function.  lieci-ious  ere  made 
based  on  cost,  compatibility/interoperability,  and  overall 
benefit  to  the  organization. 

User  Involvement.  Key  to  implementing  automated  office 
tasks  is  to  seek  user  involvement  in  the  software/- 
information  system  selection  and  design  process,  especially 
during  requirements  determination.  User  involvement  is 
referred  to  as  "participation  in  the  system  development 
process  by  representatives  of  the  target  user  group" 
(48:587).  As  Nutt  notes,  users  should  be  involved  in  the 
planning  and  defining  of  requirements  to  ensure  requirements 
are  understood  and  have  been  defined  as  necessary  to  meet 
their  office  automation  needs  (71:139-140). 

The  basic  objective  in  implementing  an  information 
system  or  software  application,  as  expressed  by  Vessey  and 
Tait,  is  to  enhance  task  performance,  and  successful 
implementation  only  happens  when  users  are  satisfied  with 
the  system  (94:10).  Empirical  evidence  supporting  this 
hypothesis  was  obtained  from  a  recent  study  (1986)  by 
Baroudi ,  Olson,  and  Ives.  It  showed  that  user  involvement 
during  information  system  development  will  enhance  system 
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usage  and  improve  user  sati'^f action  (6:586-601).  The 
implications  of  these  results  are  signilicant  for  PC 
software  applications  in  that  they  support  the  idea  -it 
users'  participation  in  the  requirements  determination 
piov-ess  and  che  acquisition  or  developuient  process  for  PC 
software  applications  may  yield  the  following  results: 

1.  Users  may  gain  more  self-esteem  from  sensing  they 
have  some  control  over  the  process. 

2.  Participating  in  the  acquisition  or  development 
process  may  be  perceived  as  challenging  and 
intrinsically  satisfying. 

3.  Better  solutions  to  office  information  problems  mai 
be  sought  since  the  users  know  more  about  their 
present  operations  than  the  computer  department 
staff . 

4.  Users  may  be  less  resistant  to  changes  in 
information  requirements  since  they  are  more 
knowledgeable  and  better  trained  in  the  use  of 
their  respective  software  applications  (62:111). 

Validation  of  Software  Requirements.  Once  software 
requirements  have  been  identified  to  automate  a  specific 
task,  they  must  be  validated.  Validation  is  the  process  of 
evaluating  software  requirements  to  ensure  they  comply  with 
the  intended  office  (knowledge)  task.  This  is  done  to 
provide  assurance  that  offices  will  acquire  or  develop 
software  products  capable  of  performing  the  required  opera¬ 
tions  necessary  to  assist  personnel  in  fulfilling  their 
overall  office  duties.  Valuable  time  and  money  can  be  s?ved 


by  having  well-defined  software  requirements  with  which  to 
evaluate  proposed  software  applications  (12:75-76). 

Acquiring  PC  software.  A  1987  report  by  the  DoD ' s 
Defense  Science  Board  recommends  the  DoD  buy  more  commercial 
software  since  it  is  "the  citeapest  and  fastest  way  to 
acquire  software"  (70:72).  However,  with  the  enormous 
amount  of  PC  software  on  the  market  today — over  10,000 
commercial  programs  as  of  1987  and  growing  exponentially-- 
care  should  be  taken  when  acquiring  tl'-3se  p-cducts  (69:114). 

To  begin,  in  an  effort  to  assist  users  in  selecting 
among  the  tremendous  array  of  software  products,  ranging 
from  word  proceoscrs  to  spreadsheets  to  program  management 
packages,  a  number  of  distribution  sources  now  exist.  These 
sources  fall  into  five  main  categories: 

1.  Retail  stores, 

2.  Mail  order  companies, 

3.  Consultants, 

4.  Software  companies,  and 

5.  Other  users  (21:104). 

Each  of  these  sources  has  pros  and  cons  which  the  user 
and/or  buyer  need  be  aware  of.  A  brief  overview  of  these 
advantages  and  disadvantages  is  given  in  the  following 
paragraphs . 

1.  Retail  stores  typically  sell  more  hardware  than 
software  because  of  the  higher  profit  margins  attainable  and 
fewer  "after-sale"  complications.  The  biggest  advantage  of 
buying  from  them  is  service.  There  is  reassurance  in 


knowing  there  is  someone  locally  available  to  answer 
questions  or  address  problems  which  may  arise.  However, 
their  disadvantages  are  primarily  two-fold:  1)  they  are 
usually  the  most  expensive  source,  and  2)  they  primarily 
carry  best-selling  programs,  which  may  not  exactly  fill  the 
users’  needs.  Retail  outlets  are  generally  a  good  choice 
for  new  users  (69:114). 

2.  Mail  order  companies  usually  sell  software  at  20  to 
50  percent  below  the  retail  price  (Needle: 114)  by  cutting 
profit-making  middle  men  out  of  the  distribution  chain. 

They  focus  efforts  on  offering  quick  service,  low  prices, 
useful  advice,  and  customer  convenience  (56*13;  61:78). 

They  normally  carry  a  broad  selection  of  software,  including 
the  best-selling  products.  They  also  offer  a  good  way  to 
find  "add-on"  and  accessory  software  programs  developed  by 
small  companies  who  have  low  advertising  budgets  Nonethe¬ 
less,  buyers  should  be  wary  of  giving  their  credit  card 
numbers  to  strangers,  varying  shipping  and  return  policies, 
and  companies  not  shipping  the  most  current  software  version 
due  to  having  large  inventories.  For  the  user  who  knows 
exactly  what  he/she  wants,  this  is  a  good  option  (69:114). 

3.  Consultants  can  be  very  beneficial  where  there  are 
highly  specialized  needs  which  require  customizing  or 
tailoring  the  software  (69:115).  For  these  needs,  a  new 
kind  of  dealer  has  emerged  called  a  value  added  dealer  (VAD) 
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or  value  added  reseller  (VAR) .  They  are  basically 
consultants  who  can  assist  personnel  in  selecting  the  most 
appropriate  software,  tailor  it  to  meet  users'  specific 
applications,  train  the  personnel  to  use  it,  and  provide 
follow-up  support  services  (21:109).  The  obvious  advantage 
to  using  consultants  is  they  can  save  users  time  in 
researching  how  to  best  tailor  the  software  to  perform  their 
specialized  tas)<.  The  disadvantage  is  the  cost  which  will 
usually  be  around  $100  per  hour  and  up  for  first-rate 
consultants.  As  well,  prices  for  continued  technical 
support  are  also  high  (69:115). 

4.  Software  companies,  which  sell  directly  to  users, 
are  usually  small  firms  which  do  not  have  a  distributor.  In 
an  effort  to  follow  in  the  footsteps  of  such  companies  as 
Borland  International  (who  became  one  of  the  largest 
software  firms  in  the  U.S.  by  direct  sales),  numerous 
companies  are  choosing  this  business  strategy.  Because  of 
the  intense  competition  among  these  firms,  the  advantages 
for  the  user  are  low  prices  and  eager  support.  Still,  not 
all  companies  have  toll-free  support  lines,  and  others  have 
only  limited  hours  of  operation  (69:115). 

5.  Other  users  include  user  groups,  mail  order  buying 
clubs,  electronic  bulletin  boards,  and  software  catalogues. 
These  sources  provide  the  various  forms  of  shareware  and 
public  domain  software  (or  freeware,  as  it  is  now  commonly 
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known).  According  to  software  analyst  David  N-eedle,  "there 
are  literally  thousands  of  public  domain  and  shareware 
programs  ranging  in  price  from  free  to  less  than  $100." 
Public  domain  software  is  non-copyrighted ,  non-copy 
protected  software  programs  which  have  been  made  available 
by  the  author  for  public  use  at  no  cost  (except  for  the 
nominal  fee  user  groups  sometimes  charge  for  finding  and 
shipping  the  program).  Shareware,  on  the  other  hand,  is 
that  PC  software  which  is  readily  available  to  the  public 
for  a  trial  period.  After  this  period,  a  small  donation  is 
requested  by  the  author  if  the  program  proves  useful  to  the 
user.  Practically  every  product  category  is  represented  by 
public  domain  software.  Various  electronic  services  like 
CompuServe  (63;115)  and  the  DoD ' s  own  Defense  Data  Network 
(DDN)  grant  easy  access  to  these  PC  programs.  Also,  some 
companies  provide  catalogues  and  low-cost  package  deals  on 
groups  of  public  domain  software  (69:115).  In  fact,  the  Air 
Force  has  its  own  catalogue  of  user  developed  PC  software 
(including  such  well-liked  programs  as  Chart  and  TDY)  to 
encourage  sharing  of  programs  Air  Force-wide  (30:8).  The 
advantage  of  this  "other  users"  software  source  is  the 
extremely  low  price.  However,  there  are  several  drawbacks: 

1.  Since  this  is  not  name-brand  software,  there  may  be 
problems  locating  the  author  if  a  problem  occurs, 

2.  Sorting  through  the  volumes  of  programs  can  take  an 
inordinate  amount  of  time,  and 
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3,  On  occasion,  some  malicious  person  will  put  a  virus 
or  destructive  bug  in  a  public  domain  software 
program  (69:115). 

These  difficulties  have  been  echoed  in  telephone  interviews 
with  various  AFSC  communications-cojuputer  systems  officers 
(CSOs)  who  gave  three  fundamental  reasons  for  the  lack  of 
use  of  these  software  sources.  They  are  listed  below. 

1.  Personnel  either  do  not  know  or  do  not  want  to  know 
what  is  available  in  freeware  or  public  domain 
software  because  they  feel  more  comfortable  with 
commercially  available  software  products. 

2.  The  available  freeware  or  public  domain  software 
does  not  meet  the  full  needs  of  the  user. 

3.  Locating  the  appropriate  software  is  a  very  tedious 
process . 

Moreover,  it  is  imperative  that  investigative  research 
be  done  prior  to  the  software  purchase  to  avoid  the  many 
pitfalls  which  beset  a  number  of  users/buyers  (69:114). 

Some  of  the  more  common  traps  are  as  follows: 

1.  Acquiring  software  which  is  incompatible  with  the 
existing  hardware. 

2.  Purchasing  software  from  small  discount  dealers  who 
do  not  stock  the  latest  software  versions. 

3.  Inadequate  software  support  is  provided  to  address 
problems  encountered  by  the  user. 

4.  Acquiring  software  before  trying  it  out  or  making 
sure  it  will  meet  the  users'  needs. 

5.  Procuring  software  or  new/upgraded  software 
versions  which  are  incompatible  with  the  existing 
software  (e.g.,  old  files  requiring  wearisome 
conversion  procedures  to  utilize  the  new  software) 
[21:106-113]  . 
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Table  3.  A  Buyers'  Guide  for  Software 
(21:109;  8:83) 


Before  You  Buv 

1.  Find  out  the  product's  suggested  retail  price. 

i 

I  2.  Next,  find  out  about  the  level  of  vendor 
j  support  and  its  cost.  (If  the  mail  order 

I  firm  has  a  toll-free  number  for  technical 

support,  buying  from  a  retailer  to  get  this 
support  may  not  be  necessary.) 

3.  If  a  dealer  wants  to  sell  the  product  at 
j  retail,  ask  him  why  you  should  buy  the 

product  from  him  over  a  discount  mail  order 
firm. 

i  4.  If  the  retail  dealer  says  they  provide 

support  for  the  software,  ask  exactly  what 
!  this  support  entails  (i.e.  What  is  the 

I  warranty  return  period?.  Does  the  retailer 

I  act  as  a  liaison  between  you  and  the 

software  manufacturer?.  How  long  does  this 
I  support  last?,  etc.). 

i  5.  A  retail  purchase  may  be  beneficial  if  you 
I  can  get  a  6-month  comprehensive  support 

package.  But  don't  take  this  offer  blindly; 
do  research  beforehand,  and  get  guarantees 
in  writing. 

6.  Whenever  possible,  try  before  you  buy.  Put 
the  software  through  xts  paces  and  read  the 
manual . 

7.  If  you  can't  try  it  yourself,  ask  user 
groups  or  bulletin  board  callers  who  have 
worked  with  the  software  to  provide  advice. 

8.  Don't  buy  copy  protected  software.  (It  has 
been  known  to  create  quite  a  few  problems, 
especially  hard  drive  failures.) 

9.  Consult  the  various  reviews  in  trustworthy 
computer  magazines  before  buying  software  or 

I  software  upgrades. 
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Caruso  has  devised  a  useful  checklist  to  help  the  user  avoid 
these  pitfalls.  The  checklist  is  found  in  Table  3.  Perhaps 
one  of  the  best  ways  to  avoid  these  various  dangers  is  to 
carefully  read  the  periodic  software  reviews  presented  in 
leading  computer  magazines  like  PC  Magazine,  Byte ,  PC  World, 
Compute  1 .  and  Personal  Computing.  These  publications 
provide  analysis  and  ratings  of  the  products  in  virtually 
all  aspects,  from  technical  design  specifications  to  user- 
oriented  features  and  applications. 

Summary 

The  literature  review  explored  some  of  the  key  aspects 
of  end-user  computing,  personal  computing,  and  considera¬ 
tions  for  PC-based  software  applications  in  office 
environments . 

As  the  fastest  growing  area  of  computer  use,  end-user 
computing  offers  considerable  benefits.  Among  them  are 
improved  decision-making,  better  control  and  acceptance  of 
information  system  implementation,  and  lower  system 
development  costs — all  resulting  from  better  and  more  timely 
access  to  information.  Along  with  this  growth  of  end-user 
computing  has  been  a  trend  toward  decentralization  in  the 
use  of  PCs.  This  trend  has  raised  considerable  concern  for 
improved  levels  of  software  support  and  end-user  satisfac¬ 
tion.  The  use  of  information  centers  may  hold  the  key  for 
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providing  guidance  in  the  development  and  management  of  PC 
software  applications  for  end-user  computing. 

The  literature  involving  personal  computing  supports 
the  idea  of  giving  individual  managers  the  flexibility  to 
use  PCs  in  the  manner  which  best  suits  the  office  task(s). 
Again,  decentralization  is  the  essential  aspect  of  this 
philosophy  since  localized  control  of  PCs  is  thought  to 
foster  better  management  decisions  and  increased 
productivity . 

Developing  the  capability  to  determine  PC  software 
requirements  should  be  the  primary  consideration  given  to 
acquiring  PC  software  applications  by  organizations.  The 
premise  is  that  one  must  first  have  a  firm  understanding  of 
the  organizational  objectives  and  office  tasks  necessary  to 
meet  those  objectives  before  selecting  a  PC  software 
application.  In  this  way,  organizations  should  be  better 
able  to  match  PC  software  products  with  their  intended 
office  task(s).  Several  strategies  and  methodologies  for 
determining  PC  software  requirements  may  be  used.  Appen¬ 
dices  C  and  D  give  explanations  of  some  common  requirements 
determination  strategies  and  methodologies.  The  strategy/- 
methodology  employed  depends  upon  the  environment  in  which 
the  requirements  determination  process  is  conducted. 
Deciding  which  tasks  to  automate  is  also  very  important 
since,  due  to  time  and  funding  constraints,  it  is  almost 
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impossible  to  automate  every  task.  As  a  result,  organi¬ 
zations  must  also  prioritize  tasks  for  automation.  Before 
purchasing  PC  software,  prior  consideration  should  also  be 
given  to  the  distribution  sources.  These  sources,  which 
include  retail  stores,  mail  order  companies,  consultants, 
software  companies,  and  other  users,  all  have  pros  and  cons 
which  organizations  should  be  aware  of.  The  checklist  in 
Table  3  provides  helpful  hints  for  making  PC  software 
purchases.  Appendix  B  provides  brief  descriptions  of  the 
top-rated  PC  software  products  in  the  application  categories 
most  common  to  the  office  environment. 
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Ill .  Methodology 


Introduction 

This  chapter  focuses  on  the  approach  used  to  answer  the 
investigative  questions  and  research  objectives  posed  in 
Chapter  I.  Discussed  are  the  target  population,  the  kind  of 
data  collected,  and  the  methods  of  data  analysis. 

Specifically,  answers  to  the  investigative  questions 
were  used  to  develop  two  PC  software  requirements  models. 
These  two  models  are  briefly  described  below: 

1.  The  Explanatory  or  Descriptive  Model.  This  model 
provides  an  explanation  of  the  way  SPOs  actually  determine 
the  need  for  and  acquire  PC  software. 

2.  The  Suggested  or  Alternative  Model.  This  is  the 
model  proposed  for  SPOs  to  use  when  defining  PC  software 
requirements  and  procuring  PC  software. 

Although  each  of  the  above  models  will  be  discussed  in 
greater  detail  in  Chapter  IV,  Results  and  Discussion,  the 
methodology  used  in  this  study  is  instrumental  to  the 
explanation  and  development  of  these  models. 

General  Method 

A  total  of  75^  personnel  assigned  to  five  SPOs  within 
AFSC  were  surveyed  to  determine  what  PC  software 
applications  SPOs  currently  use,  how  they  determine  PC 
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software  requirements,  how  effective  is  their  current 
method,  and  how  a  tailored  PC  software  requirements  model 
might  improve  the  current  procurement  system.  One  SPO  from 
each  of  the  five  product  divisions  within  AFSC  was 
selected — one  each  from  Aeronautical  Systems  Division  (ASD) , 
Space  Systems  Division  (SSD) ,  Electronic  Systems  Division 
(ESD) ,  Human  Systems  Division  (HSD) ,  and  Munitions  Systems 
Division  (MSD) .  Table  4  shows  the  respective  sizes  of  the 
SPOs  surveyed  (in  terms  of  assigned  personnel)  for  this 
study.  Personnel  surveyed  within  these  SPOs  represented 
each  of  the  functional  departments  typically  found  within  an 


Table  4.  SPO  Size  in  Terms  of  Personnel 

Aeronautical  Systems  Division  (ASD) 

s 

268 

Space  Systems  Division  (SSD) 

= 

175 

Electronic  Systems  Division  (ESD) 

= 

125 

Human  Systems  Division  (HSD) 

= 

172 

Munitions  Systems  Division  (MSD) 

= 

166 

AFSC  SPO.  Figure  1  shows  the  number  of  survey  respondents 
from  each  product  division,  while  Figure  2  shows  the  percent 
responding  by  product  division  of  the  total  surveyed. 

AFSC  SPOs  were  chosen  as  the  target  group  primarily 
because  of  their  functional  diversity  (many  different 
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Figure  1.  Number  of  Surveys  Returned  by  Product 
Division 


knowledge  tasks)  and  great  importance  to  our  nation's 
development  of  research  and  development  weapon  systems. 
Having  limited  personnel  to  perform  a  number  of  diverse  and 
important  tasks  makes  SPOs  prime  targets  for  office 
automation.  In  an  effort  to  automate  these  various  work 
tasks,  PCs  have  become  common-place  in  SPOs,  thus  making 
selection  of  the  appropriate  PC  software  a  must  for 
effective  and  efficient  office  automation. 
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Figure  2.  Percent  Responding  by  Product  Division 


of  Total  Surveyed 

Types  of  Personnel  Surveyed 

Primarily,  the  individuals  surveyed  fell  into  one  of 
three  categories:  managers,  users,  or  both.  Managers, 
branch  chiefs  (or  equivalent)  and  above,  were  surveyed 
because  they  were  deemed  to  be  in  the  best  position  to 
explain  how  their  department's  software  is  procured.  These 
individuals  were  categorized  as  heading  their  office  or 
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department  and  having  the  authority  to  validate  subordinate 
initiated  software  requirements.  Users  (individuals  within 
a  functional  office  or  department  who  use  PC  software  to 
accomplish  office  tasks)  were  surveyed  since  they  could  best 
indicate  how  well  the  software  supported  their  office  tasks. 
The  both  category  was  assigned  to  those  persons  who  use  PC 
software  in  the  accomplishment  of  office  tasks  and  also  have 
some  authority  to  validate  software  requirements. 

Proportions  of  personnel  surveyed  by  management  level  are 
shown  in  Figure  3.  Table  5  further  identifies  the  number  of 
military  and  civilian  respondents  at  each  management  level. 
Overall,  35%  (26/75)  of  those  surveyed  were  civilian  and  65% 
(49/75)  were  military.  Table  6  shows  the  number  of  military 
and  civilian  personnel  surveyed  by  grade/rank. 

The  number  of  surveys  mailed  was  based  on  the  number  of 
funci,iri*aT  'departments  (i.e.,  engineering,  program  control, 
etc.)  within  each  SPO,  with  three  surveys  provided  for  each 
department.  The  deputy  SPO  director  then  gave  each  func¬ 
tional  department  three  questionnaires  with  instructions  to 
distribute  one  to  a  middle-level  manager  (branch  chief  or 
higher)  and  the  other  two  to  lower-level  personnel. 

A  cover  letter,  addressed  to  each  deputy  director,  was 
included  with  each  package  of  surveys;  it  contained  a  brief 
explanation  of  the  survey’s  purpose  along  with  directions 
for  distribution  and  return  (see  Appendix  E) .  A  cover 
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Figure  3.  Classification  of  Survey  Respondents 
by  Management  Level 


letter  was  also  addressed  to  each  of  the  actual  survey 
participants.  It  provided  a  brief  explanation  of  the 
research  effort,  the  benefits  of  the  research  with  which  the 
participants  could  identify,  and  the  importance  of  their 
participation  to  the  study’s  success  (see  Appendix  F) .  In 
addition,  each  survey  included  an  instruction  sheet  (see 
Appendix  G)  which  described  the  research  questions  the 
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Table  5.  Classification  of  Survey  Respondents  by 
Management  Level  and  Civilian/Military 
Status 


Military 

Civilian 

Total 

Users  = 

32 

Users  = 

6 

Users  =  38 

Managers  = 

4 

Managers  = 

2 

Managers  =  6 

Both  = 

13 

49 

Both  = 

18 

26 

Both  =  31 

75 

survey  intended  to  address,  the  approximate  amount  of  time 
the  questionnaire  would  take  to  complete,  and  the  various 
question  response  forms  included  (i.e.,  multiple  choice, 
rating  scale,  etc.). 

Survey  Method  and  Design 

An  Air  Force  Manpower  and  Personnel  Center  (AFMPC) 
approved  survey  was  used  to  gather  the  data  for  this 
research  effort.  The  survey  was  designed  to  collect 
information  in  the  following  research  areas  of  SPO  PC 
software  requirements  determination: 

1 . 


How  effective  and  efficient  is  SPOs'  use  of  PC 
software? 


Table  6.  Number  of 
Personnel 

Civilian  and  Military 
Surveyed  By  Grade/Rank 

Civilian 

Military 

GS-7 

3 

E-6 

2 

GS-12  = 

4 

2nd  Lt  = 

5 

GS-13  = 

8 

1st  Lt  = 

13 

GM-13  = 

4 

Captain  = 

15 

GM-14  = 

6 

Major  = 

5 

GM-15  = 

1 

Lt  Col  = 

9 

26 

49 

2.  How  are  PC  software  requirements  currently 
determined  in  SPOs? 

3.  How  effective  are  the  processes  SPOs  currently  use 
in  determining  PC  software  requirements? 

4.  Is  there  a  better  process  SPOs  can  use  to  determine 
PC  software  requirements? 

The  survey  was  constructed  in  accordance  with  Dillman’s 
Total  Design  Method  (TDM).  TDM  is  a  method  developed  to 
assist  researchers  in  constructing  mail  and  telephone 
surveys.  It  is  designed  to  provide  responses  of  high 
quality  and  enhance  the  overall  response  rate.  The  TDM 
approach  is  predicated  on  the  notion  that  people  need  to  be 
convinced  of  two  things  before  being  willing  to  participate 
in  research:  1)  that  an  important  problem  exists  which  they 
can  identify  with  and  2)  that  their  help  is  required  to  find 
an  appropriate  solution  (31:161-163).  Because  this  approach 
relies  on  personalization  of  the  implementation  process 
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(31:163),  various  SPOs,  from  each  of  the  five  AFSC  product 
divisions,  were  contacted  by  telephone  until  one  SPO  from 
each  was  found  that  felt  the  research  was  important  to  their 
organization  and  were  willing  to  be  participants. 

Before  beginning  construction  of  the  survey,  specific 
research  areas  (as  previously  cited)  requiring  information 
were  identified.  Then  potential  survey  questions  were 
drafted  to  collect  the  required  information.  These 
questions  were  formulated  with  consideration  of  the  four 
major  decision  areas:  1)  question  content,  2)  question 
wording,  3)  question  response  structure  form,  and  4) 
question  sequence  (35:207).  In  this  manner,  a  variety  of 
dichotomous,  multiple  choice,  rating  scale,  and  open-ended 
questions  were  developed  to  assist  answering  the  investi¬ 
gative  questions  presented  in  Chapter  I.  (See  Appendix  H 
for  a  sample  questionnaire) .  This  combination  questionnaire 
was  devised  to  increase  respondent  participation  by 
providing  a  variety  of  response  forms  (23:158-162). 

To  provide  a  systematic  method  for  data  collection,  the 
survey  was  divided  into  four  parts.  The  first  section 
contained  demographic  questions,  addressing  such  things  as 
job  position,  grade/rank,  SPO  functional  area,  and  duties 
performed.  These  questions  were  useful  in  determining 
patterns  of  response  based  on  demographic  factors.  The  next 
section  consisted  of  questions  regarding  SPO  members '  use  of 
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Government-owned  office  PC  software  in  performance  of  their 
duties.  These  questions  were  essential  to  establishing  the 
present  environment  of  PC  software  applications  in  SPOs. 

The  third  section  focused  on  the  use  of  members'  personal  PC 
software  to  accomplish  work-related  tasks.  In  this  manner, 
it  was  possible  to  discover  whether  the  currently  available 
PC  software  was  sufficient  to  accomplish  office  tasks.  The 
last  section  addressed  the  ways  different  functional 
departments  actually  acquired  PC  software  tools.  This  was 
done  to  gain  further  insight  into  the  way  SPOs  presently 
address  PC  software  requirements. 

The  questionnaire  was  then  reviewed  by  several  faculty 
members  and  tested  using  nine  personnel  with  recenf  SPu 
experience.  This  was  done  to  validate  the  questions  asked 
of  respondents  and  to  insure  their  effectiveness.  Correc¬ 
tions  were  made  following  the  test,  and  the  questionnaire 
was  again  tested  using  three  additional  SPO  personnel  to 
insure  it  would  provide  the  type  of  data  the  researcher 
intended.  Failure  to  test-revise-retest  is  one  of  the  major 
reasons,  according  to  Emory,  why  poor  survey  results  are 
obtained  (35:207). 

Preliminary  Data  Collection 

Of  the  120  questionnaires  mailed,  approximately  64 
percent  of  them  were  completed  and  retume'^.  However, 
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because  two  of  those  returned  were  improperly  completed 
(i.e.,  demographic  data  missing),  63  percent  (75/120)  were 
actually  used  in  conducting  the  analysis.  Figure  4  provides 
a  breakdown  by  functional  department  of  the  number  of 
personnel  who  responded. 

The  final  research  phase  involved  compilation  of  the 
survey  data  into  categories  corresponding  to  the  investi¬ 
gative  questions  listed  in  Chapter  I.  This  compilation 
consisted  of  grouping  the  data  by  SPO  and  category  (manager, 
user,  or  both)  and  then  organizing  it  into  the  following 
reports : 

1.  Types  of  software  used. 

2.  Users  of  PC  software. 

3.  Frequency  of  Government-owned  PC  software  use. 

4.  Critical  software  used. 

5.  User  satisfaction. 

6.  Software  application  analysis. 

7.  Frequency  o'"  personal  PC  software  use. 

8.  Guidance  obtained  when  determining  requirements. 

9.  Who  defines  requirements  in  the  SPO. 

10.  Acquisition  methods  used. 

11.  Acquisition  method  effectiveness  and  efficiency. 

12.  Alternative  acquisition  methods. 


A  qualitative  assessment  of  these  reports  was  then  conducted 
to  help  answer  the  investigative  questions,  draw  conclusions 
about  the  appropriateness  of  an  alternative  PC  software 
requirements  model  (specifically  tailored  for  SPOs),  and 
make  recommendations  regarding  future  research  efforts. 
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Figure  4.  Nuiiber  of  Respondents  by  Functional 
Department 


Summary 

The  methodology  presented  in  this  chapter  was  designed 
to  assess  the  efficiency  and  effectiveness  of  the  current  PC 
software  acquisition  process  and  to  provide  a  baseline  for 
develccing  an  alternative  PC  software  requirements  model  for 
SPOs,  if  warranted.  Chapter  IV,  Results  and  Discussion, 
will  address  the  results  obtained  from  the  survey  in 
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answering  the  investigative  questions  and  their  possible 
implications  for  developing  a  PC  software  requirements  model 
for  SPOs. 
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IV.  Results  and  Discussion 


Introduction 

This  chapter  presents  the  results  obtained  from  the 
survey  and  provides  an  explanation  of  the  way  SPOs  curi^-ntly 
define  PC  software  requirements.  It  also  presents  the 
descriptive  and  alternative  PC  software  requirements 
determination  models  developed  from  the  literature  reviewed 
and  survey  data  collected.  The  results  are  organized  in  the 
context  of  the  research  investigative  questions  previously 
delineated  in  Chapter  I. 

Findings  to  the  Investigative  Questions 

1.  Who  are  the  users  of  PC  software  products  in  the  SPO? 

Of  the  75  survey  respondents,  92  percent  (69/75)  were 

identified  as  users  of  PC  software.  As  expected,  the  only 
individuals  not  using  PC  software  applications  were 
respondents  classified  as  managers.  These  individuals  were 
all  in  grades  cf  r-M-14/15  or  Lt  Col  and  were  in 
authoritative  positions  to  validate  PC  software  requirements 
for  their  branch  or  division. 

2.  a.  Wh^.t  PC  software  products  are  SPOs  currently  using? 

All  of  the  SPOs  surveyed  use  a  variety  of  products  from 
the  following  PC  software  categories:  spreadsheets,  word 
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processors,  graphics  packages,  database  managers,  integrated 
packages,  programming  languages,  and  program  managei.ient 
applications.  Others  used  include  statistical  packages, 
utilities,  and  desktop  publishing  (DTP)  software.  The 
survey  participants  identified  seven  office  (knowledge) 
tasks  which  could  be  augmented  using  PC  software 
applications.  These  tasks  included:  1)  authoring,  2) 
presentations,  3)  monitoring/controlling,  4)  diagnosis/- 
problem  solving,  5)  planning,  6)  organizing/scheduling,  and 
7)  decision-making.  Table  7  provides  a  ranking  of  the  top 
three  software  products  by  application  category  which  the 
surveyed  SPOs  identified  most  often  as  aiding  their  office 
tasks.  Rankings  were  determined  in  terms  ot  the  percentage 
of  all  participants  who  use  a  particular  product. 

(Appendix  B  provides  a  basic  guide  to  current  PC  software 
products  which  may  be  beneficial  to  SPOs.)  Clearly,  the 
most  often  identified  software  products  used  by  SPO 
personnel  were  word  processors  and  graphics  packages 
followed  by  spreadsheets,  databases,  and  integrated 
packages.  The  importance  of  word  processing  in  SPOs  takes 
on  added  significance  when  one  considers  that  65  of  the  69 
surveyed  PC  software  users,  or  94  percent,  use  a  word 
processor--either  as  a  separate  application  (like  WordStar) 
or  from  within  an  integrated  software  package  (like  Enable). 
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Table  7.  Ranking  of  the  Top  Three  Software  Products 
by  Application  Category  and  Percent  Use  of 

All  Respondents 

Word  Processors 

%  Use 

Graohics  Packages 

%  Use 

(#  used  =  58) 

{#  used  =  54) 

(1)  WordStar 

51% 

(1)  Chart 

33% 

{ 2 )  Mul tiMa  te 

11% 

(2)  Harvard  Graphics 

24% 

(3)  Microsoft  Word 

7% 

(3)  Freelance 

7% 

Soreadsheets 

%  Use 

Databases 

%  Use 

(#  used  =  30) 

(#  used  =  27) 

(1)  Lotus  1-2-3 

29% 

(1)  Dbase 

28% 

(2)  SuperCalc 

4% 

( 2 )  Condor 

3% 

{ 2 )  Quattro 

4% 

(2)  DataBase 

3% 

Integrated  Packages 

%  Use 

Programming  Languages 

%  Use 

(#  used  =  26) 

(#  used  =  19) 

(1)  Enable 

24% 

(1)  Basic 

7% 

(2)  Symphony 

5% 

(2)  GWBasic 

5% 

(2)  AMS 

5% 

(2)  Fortran 

5% 

Program  Mgt  Packages 

%  Use 

Statistical  Packages 

%  Use 

(#  used  =  18) 

{#  used  =  3) 

(1)  Time  Line 

13% 

(1)  Microstat 

4% 

(2)  Harvard  Total 

4% 

Project  Manager 

( 2 )  PMSS 

4% 

2.b.  How  often  are  these  various  PC  software  products 
used? 

Table  8  provides  a  usage  breakdown  by  software  product 
of  the  various  applications  identified  by  the  survey 
respondents.  Easily,  the  most  used  application  was  word 
processing,  with  a  median  usage  between  five  and  eight  hours 
per  week.  This  result  was  anticipated  since  SPOs  typically 


61 


Table  8.  Use  of  PC  Software  in  Hours  Per  Week 


<  2 

2-5 

5-8 

8-10 

>  101 

1 

Median 

Word  Processors 

3 

16 

17 

8 

14  1 

1 

5-8 

Graphics  Packages 

21 

19 

7 

4 

1 

3  1 
• 

2-5 

Spreadsheets 

12 

8 

3 

4 

1 

3  1 

1 

2-5 

Databases 

8 

11 

5 

2 

1 

1  1 

1 

2-5 

Integrated  Packages 

15 

5 

3 

1 

1 

2  1 

1 

<  2 

Project  Mgt  Packages 

13 

4 

1 

— 

1 

1 

<  2 

Programming  Languages 

14 

5 

— 

— 

i 

i 

<  2 

Statistical  Packages 

1 

2 

— 

— 

i 

i 

2-5 

Other  (utilities, 

DTP,  etc.) 

4 

1 

1 

“ 

1 

1 

1 

<  2 

process  a  large  number  of  various  memos,  letters,  reports, 
documents,  and  manuals  in  the  course  of  directing  a  system 
development  effort.  Graphics  packages,  spreadsheets,  and 
databases  (in  that  order)  followed  word  processors  as 
receiving  the  most  use  on  a  weekly  basis.  The  second  place 
finish  of  graphics  packages  was  initially  surprising  because 
a  1985  study  of  PC  users  in  12  organizations  revealed  the 
most  popular  applications  were  spreadsheets  and  word 
processors  (57:314,316).  But  considering  th^  substantial 
number  of  presentations  made  in  support  or  defense  of  SPO- 
directed  research  and  development  projects,  along  with 
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improvements  in  graphics  package  user-friendliness  (easy  to 
learn  and  use) ,  this  result  is  not  so  startling. 

2.  c.  How  satisfied  ire  the  users  with  these  products? 

Of  the  69  respondents  who  use  PC  software,  45  percent 
(31/69)  were  satisfied  with  the  products  currently  used  to 
augment  office  tasks.  While  only  7  percent  (5/69)  were 
completely  dissatisfied,  over  48  percent  acknowledged  some 
degree  of  dissatisfaction  with  their  office  PC  software. 
Those  PC  software  products  satisfying  user  requirements  were 
characterized  by  such  terms  as:  user-friendly,  versatile , 
fast,  compatible ,  and  having  excellent  help  features  and 
quality  output.  Dissatisfying  products  were  depicted  as 
being  inflexible,  not  user-friendly,  too  slow,  and  incom¬ 
patible.  Specifically,  four  products  were  consistently 
noted  as  having  favorable  or  unfavorable  characteristics: 
WordStar,  Chart,  Harvard  Graphics ,  and  Lotus  1-2-3. 

WordStar  was  portrayed  as  being  difficult  to  learn  and  use, 
and  having  inflexible  formatting  and  file  incompatibility 
with  spreadsheets  and  other  word  processors.  Chart  was 
noted  for  being  simple  to  use,  but  not  having  much  flexi¬ 
bility  or  output  quality.  Harvard  Graphics  was  judged  a 
terrific,  user-friendly  graphics  package.  But  respondents 
noted,  although  all  functions  are  available  through  key¬ 
strokes,  it  needs  the  use  of  a  mouse  to  efficiently  take 
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full  advantage  of  its  capability.  Having  no-  negative 
comments  was  Lotus  1-2-3  which  was  characterized  as  fast, 
powerful,  end  relatively  easy  to  use. 

3.  Which  PC  software  products  are  the  most  critical  for 

SPOs? 

Overall,  the  five  surveyed  SPOs  identified  the  most 
critical  applications  as  word  processors,  graphics,  and 
spreadsheets,  in  that  order.  Critical  applications  were 
defined  as  the  top  two  PC  software  products  the  respondents 
depended  upon  the  most.  Table  9  gives  a  breakdown  by 
functional  department  of  the  most  critical  PC  software 


Table  9.  Most  Critical  PC  Software  Applications 
by  SPO  Functional  Department 

Department 

1st  Critical 

2nd  Critical 

Project  Mgt 

Word  Processors 

Graphics 

Test  Mgt 

Word  Processors 

Graphics 

Logistics 

Word  Processors 

Graphics 

Engineering 

Word  Processors 

Spreadsheets 

Manuf acturing/QA 

Word  Processors 

Spreadsheets 

Procurement 

Word  Processors 

Spreadsheets 

Contract  Mgt 

Word  Processors 

Spreadsheets 

Management  Ops 

Word  Processors 

Databases 

Program  Control 

Spreadsheets 

Word  Processors 

Configuration  Mgt 

Databases 

Word  Processors 

applications.  As  evidenced  from  the  table,  the  most 
critical  product  for  the  SPO  is  word  processing  since  every 
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functional  detjartment  has  a  most  critical  or  second  most 
critical  need  for  this  PC  software  application. 

4.  Are  current  PC  software  products  being  used  for 

tbeir  intended  purposes? 

Judging  from  the  survey  participant's  descriptions  of 
the  tasks  performed  with  each  identified  PC  software 
product,  it  was  determined  that  most  of  the  respondents  were 
using  the  PC  software  in  ways  that  are  commonly  associated 
with  the  product  applications.  Table  10  shows  the  PC 
software  applications  used  to  support  general  office  tasks. 
Although  there  appears  to  be  some  potential  misuse  of  word 
processing  for  such  general  office  tasks  as  monitoring/- 
controlling,  organizing/scheduling,  planning,  and 
presentations,  there  is  insufficient  information  to  fully 
support  this  perception.  Moreover,  it  was  not  possible  to 
discern  whether  the  application  was  actually  being  misused 
or  if  some  survey  participants  misinterpreted  the  purpose  of 
the  question  since  many  did  not  narrate  the  specific  tasks 
for  which  they  were  applying  the  application.  In  two  cases 
respondents  stated  they  were  using  desktop  publishing  (DTP) 
software  as  a  substitute  for  a  word  processor  because  they 
needed  to  import  graphics.  Apparently,  their  available  word 
processor  did  not  have  this  capability.  Although  this 
substitute  works,  the  users  probably  would  have  been  better 
advised  to  use  a  word  processor  like  WordPerfect  5.0  or 
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Table  10.  Office  Tasks  and  Associated  PC  Software 
Applications  Used  by  Respondents 


Total  No.  Application  Categories 
Office  Tasks  of  Cases  Used  &  Number  of  Cases 


Authoring 

55 

Decision-Making 

5 

Diagnosis/ 

Problem  Solving 

11 

Monitoring/ 

Controlling 

34 

Organizing/ 

Scheduling 

24 

Planning 

15 

Presentations 

44 

Other 

17 

I 

I 


Word  Processing  =  49 
Spreadsheets  =  3 
Desktop  Publishing  =  2 
Graphics  =  1 


3 

1 


Spreadsheets 
Databases 
Project  Mgt 


Spreadsheets  =  8 
Statistical  Pkgs  =  3 

Databases  =  16 
Spreadsheets  =  14 
Word  Processing  =  3 
Graphics  =  1 


Project  Mgt  =  7 
Spreadsheets  =  6 
Databases  -  5 
Graphics  =  4 
Word  Processing  =  2 


Spreadsheets  =  9 
Project  Mgt  =  3 
Word  Processing  =  2 
Graphics  =  1 

Graphics  =  31 
Word  Processors  =  7 
Spreadsheets  =  6 

Programming  =  8 
Communications  =  5 
Utilities  =  4 


NOTE :  Some  individuals  used  more  than  one  application 

to  support  a  task. 
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Microsoft  Word  5.0  which  are  less  expensive,  user-friendly, 
and  adept  at  importing  graphics.  (See  Appendix  B  for  more 
information  on  these  products.) 

5.  Are  personally-owned  PC  software  products  used  to 
accomplish  office  tasks?  Which  ones,  and  why  are 
they  used? 

Of  the  69  survey  respondents  who  use  some  form  of  PC 
software  in  their  job  duties,  23  percent  (16/69)  ac)cnow- 
ledged  using  their  own  personal  PC  software  to  support 
office  tas)cs.  The  predominate  products  used  were  word 
processors,  followed  by  spreadsheets  and  graphics  paclcages. 
50  percent  (8/16)  of  the  individuals  used  these  products  on 
at  least  a  weelcly  basis.  When  aslced  why  personally-owned 
products  were  used,  44  percent  (7/16)  replied  they  preferred 
an  alternative  software  product  to  the  currently  available 
government-owned  software  residing  in  their  respective 
departments.  Another  31  percent  (5/16)  said  the  required  PC 
software  was  either  not  available  or  not  available  in 
sufficient  quantity  to  be  used  in  support  of  their  duties. 
These  findings  help  support  the  rationale  for  investigating 
the  PC  software  requirements  determination  process.  A 
better  process  of  identifying  requirements  may  decrease  the 
use  of  personally-owned  PC  software  by  focusing  more 
attention  on  user  needs  to  satisfy  overall  SPO  organiza¬ 
tional  requirements. 
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6.  Js  there  a  departmental  policy  (formal  or  informal) 
establishing  a  process  or  method  for  determining  PC 
software  requirements? 

Surprisingly,  only  37  percent  (28/75)  of  the 
participants  could  identify  a  policy  for  determining  PC 
software  requirements  within  their  respective  departments. 
On  the  other  hand,  19  percent  (14/75)  stated  no  policy  was 
in  effect,  and  44  percent  (33/75)  did  not  know  whether  n  PC 
software  requirements  determination  policy  existed.  This 
considerable  percentage  of  SPO  survey  respondents — 

63  percent — acknowledging  either  no  requirements  deter¬ 
mination  policy  or  no  awareness  of  a  policy  is  evidence  of 
the  lack  of  attention  being  focused  on  the  requirements 
determination  process. 

7.  What  guidance  do  SPOs  receive  when  defining  PC 
software  requirements? 

Two  types  of  guidance  were  of  interest  for  this 
investigative  question:  1)  consultant  or  base  computer 
systems  (SC)  staff  assistance  and  2)  published  sources. 
Figure  5  shows  a  breakdown  of  the  sources  users  referenced 
when  identifying  PC  software  requirements. 

While  Air  Force  regulations  and  pamphlets  (AFR  700-3, 
AFR  700-26,  and  AFP  700-30)  suggest  personnel  consult  their 
base  small  computer  technical  center  (SCTC)  and  communica- 
tions-computer  systems  (SC)  staff,  most  of  the  respondents 
sought  other  users  and  magazines ,  followed  by  SCTCs  for 
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25 


Figure  5.  Sources  of  SPO  Guidance  Used  When 

Identifying  PC  Software  Requirements 


outlining  PC  software  requirements.  There  were  also  a 
number  of  survey  respondents  who  said  they  received  no 
guidance  when  defining  requirements. 

These  results  suggest  two  implications:  1)  personnel 
are  not  aware  that  regulations,  pamphlets,  and  policy 
letters  exist  offering  guidance  for  software  requirements 
determination,  or  2)  the  regulations,  pamphlets,  and  policy 
letters  currently  in  existence  are  inadequate  to  meet,  user 
and  organizational  PC  software  requirements.  In  either 
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case,  these  results  furnish  more  support  for  devoting 
additional  attention  to  the  PC  software  requirements 
determination  process. 

8.  Who  defines  PC  software  requirements? 

The  survey  participants  who  had  identified  an  existing 
policy  for  determining  PC  software  requirements  within  their 
respective  departments  were  asked  to  identify  the  person (s) 
responsible  for  the  requirements  determination  process. 

79  percent  (22/28)  of  the  respondents  stated  their 
department  used  a  designated  computer  resource  represen¬ 
tative.  Although  this  designation  is  in  accordance  with  the 
requirements  specified  in  APR  700-26,  it  is  not  known 
whether  these  persons  actually  perform  all  the  duties 
outlined  in  the  regulation  since  no  data  was  collected  to 
corroborate  this  claim.  According  to  APR  700-26,  this 
individual,  is  responsible  for  polling  office  personnel  to 
determine  PC  software  needs,  properly  documenting  these 
needs  for  elevation  to  the  SPO's  software  approval 
authority,  submitting  the  requirements  to  the  base 
communicat ions-computer  systems  officer  (CSO)  for  validation 
and  product  selection  by  the  communications-computer  systems 
requirements  board  (CSRB),  and  monitoring  the  request 
through  the  validation  and  procurement  process.  Neverthe¬ 
less,  six  respondents  remarked  they  did  not  like  this 
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arrangement  since  it  is  normally  given  as  an  additional  duty 
to  less  experienced  personnel.  These  individuals  typically 
have  limited  knowledge  about  the  organization's  mission 
objectives  and  the  importance  of  PC  software  in  augmenting 
office  tasks  in  support  of  those  objectives. 

For  the  remaining  21  percent,  7  percent  use  their  office 
personnel  collectively  to  identify  requirements  whenever  a 
need  arises.  The  other  14  percent  did  not  know  if  there  was 
a  designated  individual  who  was  responsible  for  conducting 
the  requirements  determination  process. 

9.  What  acquisition  methods  do  SPOs  use  when  purchasing 

PC  software? 

Survey  respondents  identified  five  different  methods  for 
PC  software  acquisition: 

1.  Standard  small  computer  contract, 

2.  Sole  source/special  purchase  action, 

3.  Small  Computer  Technical  Center  (SCTC) , 

4.  Self-purchase ,  and 

5.  Other  {software  obtained  from  the  Defense  Systems 
Management  College  [DSMC]  and  vendors). 

Table  11  provides  a  percentage  breakdown  of  the  acquisition 

methods  used  based  on  the  number  of  PC  software  acquisitions 

identified.  The  most  frequently  used  methods  of  acquisition 

were  the  standard  small  computer  contract  and  sole  source  or 

special  (local)  purchase  actions.  The  predominate  use  of 

the  standard  small  computer  contract  was  expected  since  AFR 

700-26  mandates  this  purchase  method  for  most  software 
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Table  11.  SPO  PC  Software  Acquisition 

Methods 

Acauisition  Method 

Number  of 
Acauisitions 

Percent  of 
Total 

1 . 

Standard  Small 

Computer  Contract 

83 

37% 

2  . 

Sole  Source/ 

Special  Purchase 

24 

11% 

3. 

SCTC  Negotiated 

Contract 

6 

3% 

4. 

Self-Purchase 

3 

1% 

5. 

Other  (from  DSMC 
and  vendors) 

3 

1% 

6. 

Do  Not  Know 

108 

48% 

TOTAL 

227 

acquisitions.  The  48  percent  of  Do  Not  K^iow  responses 
indicates  the  PC  software  was  either  procured  before  the 
respondents'  arrival  in  the  SPO,  or  they  were  not  aware  of 
the  acquisition  method  used  once  they  had  identified  their 
requirements.  Obviously,  requirements  determination 
strategies  or  methods  would  have  limited  impact  in  the 
standard  small  computer  contract  environment  since 
organizations  are  limited  to  the  products  which  have  already 
been  prescribed  as  sufficient  to  fulfill  various  office 
management  needs.  Although  the  major  advantage  of  standard 
small  computer  contract  procurements  is  product  uniformity 
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over  a  number  of  organizations,  this  is  also  its  major 
disadvantage.  Different  organizations  and  departments  have 
varying  missions  and  objectives  which  may  mean  dissimilar 
office  tasks  requiring  different  product  applications. 
Consequently  (as  many  of  the  survey  participants  remarked), 
this  form  of  standardized  requirements  determination  (i.e., 
developing  requirements  without  regard  fjr  different 
missions  and  objectives)  has  meant  acquiring  PC  software 
applications  which  are  good  for  some  offices,  but  not  so 
good  for  others.  For  standardization  to  work,  the  mission 
objectives  and  goals  of  organizations  must  be  similar. 

10.  How  effective  and  efficient  are  SPO  PC  software 
acquisition  methods  in  providing  the  correct  or 
requested  software? 

Acquisition  Method  Effectiveness.  Over  60  percent 
(17/28)  of  the  respondents  answering  this  question  stated 
their  department's  current  procurement  process  is 
ineffective  at  providing  the  correct  or  requested  software. 

A  multitude  of  reasons  for  this  general  ineffectiveness  was 
given.  However,  the  overwhelming  reason  given  for  the 
ineffectiveness  was  the  considerable  amount  of  time  the 
Government's  procurement  system  takes  to  process  the 
necessary  paperwork.  reasons  given  are  listed  below: 

1.  Difficulty  obtaining  software  updates  (new  software 
versions ) . 

2.  Users  have  no  or  insufficient  input  to  the 
requirements  determination  process. 
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3. 


Personnel  do  not  know  who  is  responsible  for 
managing  the  PC  software  requirements  determination 
and  procurement  process--i . e . ,  no  identified  focal 
point . 

4.  Insufficient  attention  to  training  requirements. 

5.  Standardization  rules  are  inflexible. 

6.  Insufficient  attention  devoted  to  investigating  the 
"best  rated"  software  products. 

7.  Persons  who  validate  software  requirements  have 
little  knowledge  or  expertise  in  the  software 
applications  needed  to  streamline  office  tasks,  yet 
this  individual  dictates  product  use  for  everyone 
in  the  department. 

Acquisition  Method  Efficiency.  As  for  efficiency 
(measured  in  terms  of  responsiveness) ,  none  of  the 
participants  responding  to  this  question  said  their 
procurement  process  was  very  responsive,  while  65  percent 
(18/28)  of  the  them  felt  their  procurement  process  was  not 
very  responsive.  Primarily,  most  of  the  respondents  contend 
the  Government's  bureaucracy  is  the  reason  for  the  lengthy 
acquisition  time--which  ranges  anywhere  from  three  months  to 
a  year  or  never.  This  bureaucracy  accounts  for  the  lengthy 
time  to  review  and  validate  requests  and  allocate  funds  for 
purchase,  orders  being  misplaced  or  lost,  and  competitive 
buying  for  large  software  requirements.  This  perhaps  is  the 
reason  why  some  individuals  buy  their  own  software  to  timely 
bolster  their  office  tasks. 
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11.  Are  there  alternative  methods  or  improvements  which 

could  be  made  to  the  current  PC  software  procurement 

process? 

Survey  participants  supplied  a  number  of  suggestions/- 
comments  to  improve  the  current  PC  software  acquisition 
process.  These  suggestions/comments  were  used  to  assist 
development  of  the  proposed  requirements  determination 
model.  Of  the  23  responses  made  to  this  question,  only 
17  percent  (4/23)  suggested  methods  for  increased  standard¬ 
ization  of  the  procurement  process  (like  mandating  one  word 
processor  for  all  of  DoD) ;  whereas,  83  percent  (19/23) 
suggested  ways  consistent  with  tailoring  requirements  to 
meet  SPO  mission  objectives  and  goals  (like  letting 
departments  determine  their  own  requirements  and  make 
special  or  local  purchases) .  A  tailored  approach  would  mean 
each  SPO  or  functional  department  would  have  the  respon¬ 
sibility  and  authority  to  determine  requirements  and 
purchase  software  which  best  meets  the  particular  needs  of 
the  SPO  or  functional  department.  A  comprehensive  listing 
of  participants'  comments/suggestions  is  located  in 
Appendix  I. 

Unidentified  Requirements.  Participants  were  asked  to 
identify  primary  office  tasks  which  could  be  supported  with 
PC  software,  but  are  currently  unsupported.  It  is  quite 
evident  after  reviewing  the  respondents'  comments  that  the 
current  PC  software  acquisition  methods  used  are  inadequate 


7b 


at  identifying  requirements  and  procuring  the  correct  or 
requested  software.  Several  cases  were  noted  where  the 
current  acquisition  methods  either  inadequately  identified 
2r6QUX2r6Iiicno  s  or  where  users  had  difficulty  purchasing  the 
properly  identified  PC  software  product.  Some  of  these 
cases  are  presented  below: 

1.  Eight  of  the  respondents  said  the  reason  for  their 
non-support  was  the  inadequacy  of  the  present  software 
acquisition  process  to  supply  the  necessary  product. 

2.  Another  33  percent  (6/18)  who  had  a  total  of  12 
different  duties  going  unsupported  replied  they  did  not  know 
whether  the  duties  could  be  supported  when,  in  fact,  some  of 
them  could.  For  instance,  two  individuals  in  contract 
management  and  procurement  did  not  realize  the  potential  of 
decision  support  system  (DSS)  software  (like  Expert  Choice 
or  Decision  Aid)  to  assist  source  selection  decisions.  Such 
systems  may  prove  very  useful  in  this  regard  since  they  lend 
structure  to  unstructured  decision  problems.  These  programs 
have  also  been  used  in  an  academic  environment  to  aid  source 
selection  evaluations. 

3.  In  several  instances,  participants  reported  no  use 
of  software  to  support  a  primary  duty  when  perhaps  they 
could  have  been  supported.  For  example,  a  configuration 
manager  and  management  operations  manager  could  use  a 
database  management  system  (like  Dbase  or  Paradox)  to  track 
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system  configuration  changes  and  manage  personnel  issues 
(i.e.,  track  performance  reports,  inbound/outbound  assign¬ 
ments,  etc.),  respectively.  Also,  68  percent  (15/22)  of 
branch  and  division  chiefs  stated  their  primary  duties  as 
managing  the  day-to-day  activities  of  their  departments,  yet 
none  of  them  mentioned  using  a  personal  information  manager 
(PIM)  like  Agenda  or  Grandview  which  may  help  managers 
automate  these  tasks.  PIMs  help  managers  organize  the 
tidbits  of  information  which  typically  cross  their  desks 
every  day — like  notes,  phone  messages,  etc.  This  is  not  to 
say  PIMs  are  the  answer  for  all  managers,  but  they  do  offer 
potential  benefits  to  those  who  would  like  to  automate  their 
day-to-day  activities.  (See  Appendix  B  for  more  information 
on  PIMs.) 

4.  A  number  of  respondents  complained  of  the  lack  of 
existing  software  availability.  For  instance,  a  director  of 
manufacturing/quality  assurance  remarked  that  his  people 
lost  time  waiting  to  use  a  software  product  available  only 
in  limited  quantities. 

5.  In  general,  the  survey  participants  were  not  taking 
advantage  of  spreadsheets  and  databases  to  track  and  monitor 
various  crogram  activities,  like  system  anomalies, 
engineering  change  proposals  lECPs)  and  associated  comments, 
personnel  issues,  etc.  In  addition,  project  management 
software,  like  Time  Line  and  SuperProject  Plus,  were  not 


being  used  as  prevalently  as  expected.  These  relatively 
inexpensive  products  can  prove  beneficial  in  helping 
personnel  analyze  the  three  main  phases  of  virtually  every 
project:  planning,  implementation,  and  evaluation  by 

breaking  the  project  down  into  its  component  parts  to 
facilitate  easier  scheduling  of  project  activities  (39:90). 
(See  Appendix  B  for  more  information  on  project  management 
software . ) 

Cases  such  as  these  lend  further  support  to  the  premise 
that  current  SPO  acquisition  policies  do  not  devote  adequate: 
attention  to  requirements  determination.  If  they  did,  then 
many  of  the  cases  presented  above  possibly  would  have  been 
precluded  as  a  result  of  having  properly  identified  software 
requirements . 

The  Actual  vs  The  Proposed  PC  Software  Requirements  Model 

The  Descriptive  (Actual)  Model.  This  model  describes 
the  general  method,  based  on  the  minority  of  survey 
participants  who  could  identify  the  process,  which  is 
currently  used  by  SPOs  to  determine  their  PC  so  tware 
requirements.  This  general  methodology  is  as  follows: 

1.  Personnel  identify  a  need  for  an  application  which 
will  assist  their  office  tasks. 

2.  Individuals  primarily  rely  on  other  users  and 
magazines  to  identify  specific  software  products  to 
support  specified  office  tasks. 

3.  Personnel  notify  the  designated  organizational 
computer  representative  who  checks  and  consolidates 
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the  requests  from  other  offices.  The  computer 
representative  then  seeks  intermediate-level 
approval/validation  of  the  requests  from  the  SPO 
director  or  his  designated  representative. 

4.  Requirements  then  are  routed,  lAW  AFR  700-26, 
through  a  computer  systems  resource  document  (CSRD) 
to  the  base  communications-computer  systems  office 
(SC)  for  final  approval/validation. 

5.  Upon  approval  from  SC,  the  computer  systems 
requirements  board  (CSRB)  attempts  to  procure  the 
product  through  the  standard  small  computer 
contract,  if  the  application  (not  product  brand 
name)  is  available.  If  sufficient  justification  is 
given  to  warrant  a  specific  product  (by  brand 
name) ,  then  a  sole  source  contract  effort  is 
initiated.  However,  this  is  all  contingent  upon 
funds  availability  and  base-wide  requirements 
priorities . 

The  major  advantage  of  this  methodology  is  the  ease  by 
which  users  can  identify  means  of  simplifying  various  office 
tasks.  Personnel  do  not  have  to  seek  external  advice  to 
help  them  determine  PC  software  requirements.  Nonetheless, 
there  are  two  serious  drawbacks  with  this  approach.  First, 
this  descriptive  model  is  hindered  by  bureaucracy  when  it 
comes  time  to  actually  procure  the  requested  software.  It 
takes  much  too  long  (from  three  to  six  months  or  longer)  to 
get  the  application  to  the  user.  Even  if  the  application 
does  make  it  to  the  user,  there  is  no  guarantee  that  this 
application  will  be  the  application  requested  by  product 
name.  Consequently,  this  is  part  of  the  reason  why  over 
half  of  the  respondents  expressed  some  dissatisfaction  with 
the  products  they  are  currently  using.  Second,  this 
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methodology,  although  granting  autonomy  to  the  user  to 
identify  requirements,  does  not  impose  adequate  controls  on 
the  requirements  determination  process.  Proper  controls  are 
necessary  to  ensure  organizational  requirements  are  being 
met  since  there  is  little,  if  any,  mating  of  user  identified 
requirements  with  those  of  the  organization  (i.e.,  its 
mission  objectives  and  goals).  For  instance,  say  indivi¬ 
duals  within  a  SPO  branch  decide  a  DTP  package  will  meet 
their  word  processing  needs  because  they  need  the  capability 
to  incorporate  graphics  with  text.  However,  everyone  else 
in  the  SPO  uses  a  word  processor  like  WordStar.  If  there  is 
a  need  for  organizations  to  transfer  files  between  branches, 
departments,  etc.  a  compatibility  problem  may  arise  because 
the  personnel  using  WordStar  may  not  be  able  to  convert  the 
DTP  file  to  a  WordStar  compatible  file.  If  the  organization 
were  making  the  decision  today,  a  better  choice  would  be  the 
selection  of  another  word  processor  like  WordPerfect  5.0  or 
Microsoft  Word  5.0  which  could  both  import  graphics  and  do 
file  conversion.  Departments  must  consider  not  only  their 
own  processing  needs  but  the  need  for  compatibility  and 
interoperability  with  other  departments  if  they  intend  tc 
share  information.  This  resulting  improper  solution  to  an 
office  task  may  have  been  precluded  had  the  organizational 
requirements  been  highlighted  and  given  priority  in  the 
requirements  determination  process. 
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stepwise  methodology  is  proposed  to  improve  the  PC  software 
requirements  determination  process  for  SPOs.  It  takes  into 
account  the  literature  reviewed  in  Chapter  II  and  Appendices 
C  and  D  and  the  survey  responses  gathered  in  support  of  this 
research  effort.  Specifically,  this  suggested  model  is 
designed  to  improve  the  way  SPO  personnel  define,  justify, 
and  satisfy  their  PC  software  requirements.  The  first-year 
model  consists  of  the  following  steps: 

1.  Select  a  computer  resource  committee  of 
knowledgeable  PC  software  users  to  direct  the  PC 
software  requirements  process.  This  committee 
should  consist  of  three  or  five  individuals 
selected  by  the  SPO  director  and  his  staff. 

Rationale:  Although  organizations  have  the 

flexibility  to  choose  either  an  individual  or  a 
committee  for  this  purpose,  there  is  supporting 
evidence  for  using  committees  that  approach 
requirements  determination  from  a  management 
perspective — deciding  upon  those  requirements  most 
important  to  achieving  mission  objectives  and  goals 
(88:47-49).  They  will  provide  a  visible  focal 
int  for  PC  software  concerns  comprised  of 
...idividuals  dedicated  to  finding  better  uses  of  PC 
software  to  accomplish  office  tasks. 

2.  Set  aside  a  budget  for  SPO  specific  software 
purchases. 

Rationale :  Having  a  budget  already  in  place 

will  help  cut  the  time  typically  spent  trying  to 
allocate  funds  for  expenditures.  Because  SPOs 
typically  have  more  flexibility  than  other 
organizations  to  shift  funds  from  one  account  to 
another,  this  set  aside  should  not  be  very 
difficult . 

3.  Define  the  SPO's  organizational  mission  objectives 
and  goals. 


Rationale:  This  will  help  SPO  members 
understand  the  organization's  purpose  and  consider 
issues  like  compatibility  and  interoperability 
during  the  requirements  determination  process. 

This  step  should  also  help  members  understand  how 
PC  software  will  help  them  achieve  organizational 
objectives  (29:5). 

4.  Identify  current  and  potential  future  critical 
office  functions  and  outputs  necessary  to  satisfy 
SPO  mission  requirements.  This  may  be  done  by 
interviewing  the  branch  (3-ltr)  chiefs,  division 
(2-ltr)  chiefs,  and  the  SPO  director's  staff  (SPO 
director,  deputy  SPO  director,  and  technical 
advisor) . 

Rationale i  The  goal  of  this  step  is  to  match 
critical  office  functions  to  mission  objectives  and 
goals  (25:473-496). 

5.  Survey  all  SPO  personnel  to  identify  bottlenecks 
(tasks  which  limit  or  prevent  user  efficiency  and 
effectiveness)  in  the  accomplishment  of  office 
tasks.  Start  by  determining  the  tasks  personnel 
perform  to  accomplish  their  duties,  and  examine  the 
ways  in  which  PC  software,  or  PC  software  upgrades, 
might  support  those  tasks  for  better  efficiency  and 
effectiveness . 

Rationale:  This  concept  of  cognitive  mapping 
enables  personnel  to  focus  on  those  tasks  deemed 
most  critical  to  the  organization  (45:293-295).  In 
addition,  user  involvement  in  the  planning  and 
defining  of  requirements  is  necessary  to  ensure 
requirements  are  defined  to  meet  offj.ce  automation 
needs  (71:139-140).  It  also  aids  the  successful 
implementation  of  the  software  since  users  should 
be  more  satisfied  with  the  products  selected 
(94:10) . 

6.  Separate  those  office  tasks  -yrhich  can  be 
streamlined  with  PC  software  from  those  that  have 
been  sufficiently  augmented  and  those  that  can  not 
be  streamlined. 

Rationale :  The  committee  may  want  to  solicit 

outside  sources  of  expertise,  like  the  base  SC 
staff,  to  help  them  determine  which  tasks  would 
benefit  most  from  PC  software  support  and  make  the 
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appropriate  recommendations  to  this  effect 
(67:45-47) . 

7.  Prioritize  those  tasks  which  can  be  streamlined  in 
order  of  their  probability  for  lowering  mission 
costs  and  enhancing  mission  success.  Conducting 
interviews  with  the  branch  (3-ltr)  and  division  (2- 
Itr)  chiefs  and  SPO  director’s  staff  should  supply 
this  information. 

Rationale i  This  step,  taken  from  the  An r 
Force’s  Information  Systems  Requirements  Analysis 
(ISRA)  method,  helps  supply  justification  for 
selecting  the  requirements  to  automate  (29:20). 

8.  Group  the  tasks  selected  for  automation  with  PC 
software  into  their  primary  application  categories 
(i.e.,  word  processors,  spreadsheets,  etc.). 

Rationale :  Gr  >uping  the  tasks  in  this  manner 

will  facilitate  easier  final  selection  of  the  most 
appropriate  PC  software  product  from  its  parent 
application  category. 

9.  Employing  such  sources  as  the  SCTC,  electronic 
bulletin  boards,  magazines ,  vendors,  and  other 
users,  select  a  few  of  the  most  appropriate 
software  products  for  evaluation  which  will 
accomplish  the  defined  office  task(s).  Appendix  B 
may  prove  useful  for  selecting  products  for 
evaluation. 

Rationale :  The  survey  participants  identified 

these  sources  as  those  they  turned  to  for  guidance 
in  assisting  selection  of  PC  software.  There  is 
also  evidence  supporting  the  use  of  these  sources 
to  assist  personnel  in  choosing  from  the  vast  array 
of  software  products  available  (21:104). 

10.  Evaluate  the  possible  software  packages  in  terms  of 
the  following  factors: 

a .  Cos t 

b.  Performance  (i.e..  How  well  does  the  product 
meet  the  intended  requirement?) 

c.  Compatibility  and  interoperability  of  the 
product  with  existing  and/or  pending  haz jware 
and  software  acquisitions  (i.e.,  Is  there 
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sufficient  RAM  in  the  present  hardware  to  run 
this  software?.  Does  the  product  easily 
export/import  files?.  Is  it  compatible  with  the 
product (si  other  departments  with  whom  the 
users  interface  use?,  etc.) 

d.  Legality  of  use  (i.e.,  public  domain  software 
vs  shareware,  copyprotection,  etc.) 

e.  User-friendliness  (i.e..  How  easy  is  it  to 
learn  and  use?) 

f.  Training  requirements  (i.e.,  How  much  is 
needed?.  How  much  does  it  cost?,  When  is  it 
available?,  etc.) 

Rationale :  These  evaluation  criteria  were 

taken  from  AFP  700-30  and  the  feedback  obtained 
from  the  survey  participants  on  Questions  12-14, 
and  17.  It  should  allow  SPOs  to  effectively 
evaluate  PC  software  products  for  selection. 

11.  After  soliciting  feedback  from  the  prospective 
primary  users,  select  the  product  which  best  meets 
the  need  and  criteria. 

Rationale:  PC  software  products  should  be 

evaluated  with  the  objective  of  matching  the  best 
possible  product  with  the  intended  office  task. 

12.  Submit  the  request  to  the  SPO  director  or  his 
designated  representative  for  approval . 

Rationale ;  This  is  an  important  aspect  since, 
ordinarily,  requests  are  approved  by  SC.  However, 
the  SPOs  should  have  the  final  approval  authority 
for  purchases  outside  of  the  standard  small 
computer  contract  since  they  are  in  the  best 
position  to  ascertain  what  products  will  best  fit 
their  needs.  This  is  the  same  line  of  reasoning 
many  authorities  have  used  to  justify  decentralized 
control  and  decision-making  (58:5-11). 

13.  Purchase  the  desired  software.  These  purchases 
should  be  made  through  the  S^andard  Small  Computer 
Contract  if  the  requested  product  is  available  by 
this  means.  If  not,  use  a  SCTC  negotiated  contract 
or  sole  source  or  local  purchase  action. 
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Rationale :  Although  the  purchase  process  would 

perhaps  be  faster  if  organizations  were  allowed  to 
make  direct  purchases,  the  Government  procurement 
process  for  software  is  mandated  in  AFR  700-26. 

This  study  did  not  specifically  address  improve¬ 
ments  to  the  purchase  process. 

14.  Use  the  product  for  a  specified  period  of  time 
(perhaps  tf^o  to  three  months),  and  then  conduct  a 
follow-up  evaluation. 

Rationale :  The  purpose  of  the  follow-up 

evaluation  is  to  ensure  the  product  is  meeting  its 
intended  purpose.  Obtaining  feedback  is  an  essen¬ 
tial  element  of  good  management  control 
(25:485-486) . 

15.  Conduct  re-evaluations  at  least  once  per  year. 

Rationale :  This  will  ascertain  whether  the 

product  is  continuing  to  satisfy  the  intended 
r'^guirement  and  whether  a  new  product  or  upgrade 
(new  version)  is  needed--part  of  the  feedback 
mechanism . 

Important  to  note  is  that  this  proposed  methodology 
bypasses  the  communications-computer  systems  requirements 
board  (CSRB).  The  primary  rationale  is  that  the  CSRB  cannot 
guarantee  a  requirement  will  be  funded  since  they  have  a 
limited  amount  of  funds  to  manage.  Funds  are  allocated  to 
the  CSRB  to  help  meet  organizational  needs  base-wide  which 
usually  means  organizations  will  not  have  all  of  their  needs 
met  within  their  requested  time  frame.  Some  organizations 
will  inevitably  have  unfunded  requirements.  These 
requirements  may  or  may  not  get  funded  depending  upon  when 
monies  become  available  again  and  the  priority  given  to 
those  particular  requirements.  This  method  is  more 
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efficient  because  it  gives  SPOs  the  authority  to  procure  the 
software  application  they  desire  when  they  want  it  (i.e.,  in 
a  more  timely  fashion) .  It  also  ensures  the  specific 
product  requested  is  the  one  which  will  be  procured.  The 
present  CSRB  system  does  not  guarantee  the  product  requested 
will  be  the  product  procured  to  fulfill  a  valid  requirement. 

As  stated  before,  the  proposed  model,  as  previously 
defined,  is  applicable  to  a  first-year  PC  software 
requirements  analysis.  For  subsequent  years  and  out  of 
cycle  PC  software  requirements,  the  individual  or  department 
need  only  identify  the  requirement  to  the  requirements 
committee.  The  committee  will  then  compare  this  requirement 
to  the  previously  prioritized  tasks  in  Step  7  to  determine 
whether  the  requirement  has  already  been  prioritized  or 
needs  to  be  prioritized.  If  the  requirement  already  exists, 
the  requirements  committee  will  just  continue  from  Step  8; 
otherwise,  they  will  prioritize  the  requirement  lAW  Step  7 
and  continue  the  process.  Using  this  suggested  or 
alternative  model  may  result  in  better  mission  need  and 
office  task  analysis  and  thus,  better  PC  software  product 
procurements  to  fulfill  those  needs. 

Summary 

Presented  in  this  chapter  are  the  findings  of  the 
research  investigative  questions  and  analysis  of  the  survey 
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responses  from  75  individuals  representing  five  SPOs — one 
each  from  the  five  product  divisions  in  AFSC.  These 
findings  and  analyses  were  used  to  construct  the  present  PC 
software  requirements  determination  model — called  the 
descriptive  model — used  by  SPOs.  Along  with  the  literature 
reviewed  from  Chapter  II,  these  findings  and  analyses  were 
also  used  to  develop  the  proposed  Suggested  or  Alternative 
SPO  PC  Software  Requirements  Determination  hodel.  This 
model  potentially  outlines  a  more  efficient  and  effective 
means  of  specifying  PC  software  requirements  in  SPOs,  but  it 
remains  to  be  tested  to  this  effect.  The  basic  approach  is 
to  match  SPO  mission  objectives  and  functions  to  critical 
office  tasks  and  then  determine  the  best  software  products 
available  to  assist  personnel  in  accomplishing  those  tasks. 
Chapter  V,  Conclusions  and  Recommendations  is  based  on  tne 
findings  and  analyses  and  the  descriptive  and  suggested  PC 
software  requirements  determination  models  discussed  in  this 
chapter . 
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V.  Conclusions  and  Recommendations 


Introduction 

This  chapter  provides  answers  to  the  research  objectives 
identified  in  Chapter  I,  and  conclusions  regarding  the 
descriptive  and  alternative  requirements  determination 
models  presented  in  the  previous  chapter  for  SPO  PC 
software.  It  also  discusses  recommendations  for  future 
research  associated  with  PC  software  requirements 
determination. 

Answers  to  Research  Objectives 

Objective  1:  Determination  of  the  effectiveness  of 

currently  available  PC  software  applications 
used  to  support  SPO  tasks. 

Current  PC  software  applications  are  meeting  most  SPO 
identified  office  needs  with  word  processors  touted  as  the 
most  critical  software  applications.  However,  SPO  personnel 
are  not  fully  satisfied  with  their  PC  software  products, 
citing  such  reasons  as  product  incompatibility,  lack  of 
user-friendliness,  slowness,  and  inflexibility  as  the  causes 
of  their  dissatisfaction.  Also,  personnel  were  somewhat 
disgruntled  regarding  the  lack  of  updates  (new  versions)  to 
their  presently  available  PC  software  products.  In  many 
instances,  if  updates  were  readily  available,  jobs  presently 
unsupported  could  be  supported  with  the  same  product  line. 
For  example,  many  users  of  earlier  WordStar  versions  are 
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frustrated  with  its  inability  to  import  graphics  and  conduct 
file  conversion  (i.e.,  (WordStar  to  ASCII,  etc.).  f/ordStar 
5.0  has  this  capability,  but  users  have  had  little  success 
acquiring  it  although  earlier  versions  were  on  the  Standard 
Small  Computer  Contract.  The  inability  to  acquire  software 
updates  causes  the  available  PC  software  to  be  less  effec¬ 
tive  than  it  could  be.  Moreover,  a  number  of  software 
requirements  which  could  be  met  with  existing  PC  software 
either  go  unidentified  or  unsupported.  Both  of  these 
problems  could  be  lessened  with  better  requirements 
determination  procedures. 

Objective  2:  Determination  of  the  current  processes  SPOs 
use  to  identify  PC  software  requirements . 

The  majority  of  surveyed  personnel  sought  other  users 
and  magazines  when  guidance  was  requested  in  determining 
requirements,  instead  of  the  SC  staff  as  outlined  in 
Government  regulations.  In  addition,  several  respondents 
sought  no  forms  of  guidance  during  requirements  deter¬ 
mination.  This  implies  one  or  both  of  the  following: 

1)  personnel  are  not  aware  various  regulations  and  policy 
letters  exist  offering  guidance  for  software  requirements 
determination,  or  2)  the  regulations  and  policy  letters  in 
existence  are  inadequate  at  assisting  personnel  to  define 
their  PC  software  requirements. 
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Moreover,  over  60  percent  of  those  surveyed  were  unable 
to  identify  any  existing  policy  within  their  respective 
departments  for  determining  PC  software  requirements.  This 
may  or  may  not  be  disturbing  depending  upon  whether  these 
unknowing  individuals  have  a  need  to  identify  PC  software 
requirements.  If  they  do  have  a  requirement  but  do  not  know 
the  means  to  identify  it,  then  this  requirement  may  go 
unidentified.  Those  persons  who  did  recognize  an  existing 
policy  overwhelmingly  named  a  designated  computer  resource 
representative  as  the  person  responsible  for  directing  their 
organization's  requirements  determination  process  as 
stipulated  by  AFR  700-26.  But  this  method  can  potentially 
place  too  much  responsibility  on  one  individual  who  many 
times  is  too  inexperienced  to  make  the  best  decisions. 

Both  of  these  findings  suggest  the  current  PC  software 
requirements  identification  methods  are  inadequate.  A  good 
requirements  determination  methodology  should  be  visible  to 
all  personnel  and  employ  persons  to  head  the  process  who  are 
knowledgeable  of  the  organization's  objectives  and  functions 
and  the  importance  of  PC  software  in  supplementing  office 
tasks  in  support  of  those  objectives  and  functions. 

Objective  3:  Determination  of  the  methods  SPOs  currently 
use  to  acquire  PC  softifare  products . 

Not  surprisingly,  the  most  frequently  used  procurement 
method  is  the  Standard  Small  Computer  Contract  which  is 
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specified  by  AFR  700-26.  In  addition,  numerous  purchases 
are  accomplished  using  a  sole  source  or  special  (local) 
purchase  action. 

Although  procurements  lAW  the  Standard  Small  Computer 
Contract  assure  product  uniformity  between  organizations, 
care  must  be  taken  to  develop  requirements  with  regard  for 
different  mission  objectives  and  functions.  The  rationale 
is  that  organizations  with  different  mission  objectives  and 
functions  may  have  different  PC  software  needs.  Since  such 
product  standardization  may  only  work  well  when  organiza¬ 
tions  share  similar  mission  objectives  and  functions, 
avenues  should  remain  available  for  sole  source  or  special 
purchase  actions.  These  actions  should  be  left  to  the 
discretion  of  the  individual  SPO  organizations  as  they  are 
in  the  best  position  to  determine  what  their  special 
requirements  are. 

Objective  4:  Determination  of  the  effectiveness  of  present 
PC  software  requirements  identification  and 
procurement  practices . 

Current  SPO  requirements  identification  methods  are 
inadequate  to  fulfill  organizational  needs.  The  reason  for 
this  inadequacy  is  that  not  enough  emphasis  is  placed  on 
this  section  of  the  procurement  process.  Personnel  are  not 
aware  of  the  regulations  and  policies  governing  PC  software 
requirements  identification,  and  they  generally  do  not  know 
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who  is  responsible  for  conducting/managing  the  requirements 
determination  process. 

Present  SPO  procurement  practices  are  also  lacking. 

They  are  deficient  in  both  supplying  the  correct  or 
requested  software  and  doing  it  in  a  timely  manr-^r.  The 
reason  for  this  ineffectiveness  and  inefficiency  primarily 
rests  with  the  Government's  procurement  system.  This  system 
takes  a  long  time  to  process  a  request,  and  there  is  no 
guarantee  the  organization  will  receive  the  particular 
software  requested.  However,  this  is  not  all  the  fault  of 
the  CSRB.  They  are  hampered  by  limited  budgets  which 
results  in  a  number  of  unfunded  organizational  requirements. 
Nonetheless,  decentralizing  the  procurement  process  so 
individual  organizations  could  be  responsible  for  small, 
non-standard  (SPO-unique) ,  off-the-shelf,  PC  software 
expenditures  would  greatly  enhance  the  process.  In  this 
way,  SPOs  would  most  likely  receive  the  correct/requested  PC 
software  in  a  timely  fashion. 

Objective  5:  Determination  of  whether  the  development  of  a 
tailored  PC  software  requirements  model  for 
SPOs  might  improve  the  PC  software  acquisition 
process . 

From  the  literature  reviewed  and  the  survey  data 
collected,  it  is  apparent  that  improvements  made  to  the 
requirements  determination  process  is  a  key  step  in 
improving  the  PC  software  acquisition  process.  Although  the 
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CSRB  serves  a  legitimate  purpose  trying  to  prioritize  and 
meet  base-wide  organizational  requirements  with  limited 
funds,  Government  bureaucracy  is  acknowledged  by  the 
researcher  as  a  major  obstacle  to  improving  the  PC  software 
procurement  process.  A  sound  requirements  determination 
process  is  an  essential  first  step  to  ensure  the  right 
software  is  identified  to  fulfill  the  mission  need.  Without 
this  requirements  determination  step,  actual  procurement 
effectiveness  and  efficiency  is  meaningless  if,  as  three 
respondents  remarked,  the  acquired  software  is  inadequate  to 
meet  the  mission  need.  Thus,  the  suggested  model  offers 
substantial  improvement  over  the  descriptive  model  {the 
methodology  presently  used  by  SPOs)  described  in  Chapter  IV. 
It  focuses  on  matching  SPO  mission  objectives  and  functions 
to  critical  office  tasks  and  then  investigating/selecting 
those  PC  software  products  best  suited  to  fulfill  office 
task(s)  in  support  of  mission  needs.  This  methodology 
relies  on  the  ability  of  the  SPO  director  and  his  staff  to 
select  a  committee  of  both  mission  and  PC  software 
knowledgeable  personnel.  These  persons  must  be  able  to 
consolidate  mission  objectives  and  functions  with  a 
prioritized  list  of  critical  SPO  tasks  which  could  be 
augmented  using  PC  software  to  support  the  mission 
objectives  and  functions.  The  committee  must  also  be 
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responsible  for  investigating  and  recommending  the  best 
possible  PC  software  product  to  meet  the  desired  task(s). 


Recommended  Research  Solution 

The  research  developed  Suggested  or  Alternative  Model  is 
recommended  to  assist  SPOs  in  the  requirements  determination 
process  for  PC  software.  Employment  of  this  methodology 
should  help  SPOs  better  define,  justify,  and  satisfy  their 
PC  software  requirements.  The  steps  to  the  suggested  or 
alternative  PC  software  requirements  model  are  recapped 
below : 

1.  Select  a  computer  resource  committee  of 
knowledgeable  PC  software  users  to  direct  the  PC 
software  requirements  pr-cess. 

2.  Set  aside  a  budget  for  SPO  specific  software 
purchases . 

3.  Define  the  SPO's  organizational  mission  objectives 
and  goals. 

4.  Identify  current  and  potential  future  critical 
office  functions  and  outputs  necessary  to  satisfy 
SPO  mission  requirements. 

5.  Survey  all  SPO  personnel  to  identify  bottlenecks 
(tasks  which  limit  or  prevent  user  efficiency  and 
effectiveness)  in  the  accomplishment  of  office 
tasks . 

6.  Separate  those  office  tasks  which  can  be 
streamlined  with  PC  software  from  those  that  have 
been  sufficiently  augmented  and  those  that  can  not 
be  streamlined. 

7.  Prioritize  those  tasks  which  can  be  streamlined  in 
order  of  their  probability  for  lowering  mission 
costs  and  enhancing  mission  success. 
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8.  Group  the  tasks  selected  for  automation  with  PC 
software  into  their  primary  application  categories 
(i.e.,  word  processors,  spreadsheets,  etc.). 

9.  Employing  such  sources  as  the  SCTC,  electronic 
bulletin  boards,  magazines,  vendors,  and  other 
users,  select  a  few  of  the  most  appropriate 
software  products  for  evaluation  which  will 
accomplish  the  defined  office  task(s). 

10.  Evaluate  the  possible  software  packages  in  terms  of 
the  following  factors: 

a.  Cost 

b.  Performance 

c.  Compatibility  of  the  product  with  existing 
and/or  pending  hardware  and  software 
acquisitions 

d.  Legality  of  use 

e.  User-friendliness 

f .  Training  requirements 

11.  After  soliciting  feedback  from  the  prospective 
primary  users,  select  the  product  which  best  meets 
the  need  and  criteria. 

12.  Submit  the  request  to  the  SPO  director  or  his 
designated  representative  for  approval. 

13.  Purchase  the  desired  software. 

14.  Use  the  product  for  a  specified  period  of  time 
(perhaps  two  to  three  months) ,  and  then  conduct  a 
follow-up  evaluation. 

15-  Conduct  re-evaluations  at  least  once  per  year. 

In  addition,  some  SPOs  may  find  portions  or  the 
questionnaire  in  Appendix  H  useful  (as  did  one  SPO  during 
this  research  effort)  in  helping  them  identify  office  tasks 
which  may  potentially  benefit  from  PC  software  applications. 


Specifically,  Survey  Questions  3  through  8  may  prove  useful 
for  this  task.  It  may  also  help  SPOs  identify  those  office 
tasks  where  modifications  to  existing  PC  software  are 
necessary  (i.e.,  updated  software  versions  or  different 
software  products)  to  improve  current  office  task  support. 
Questions  11  through  14  may  be  beneficial  for  this  purpose. 

Recommendations  for  Future  Research 

The  conclusions  drawn  from  this  study  are  assumed  to  be 
an  accurate  depiction  of  the  SPO  organizations  surveyed  and 
were  meant  to  be  generalized  to  all  SPOs  within  AFSC. 
However,  due  to  the  limited  sample  size  (75  total 
respondents)  and  SPOs  surveyed  (one  from  each  of  the  five 
product  divisions),  these  generalizations  nay  not  hold  for  a 
larger  sample  size  of  SPO  organizations  and  personnel. 
Therefore,  future  researchers  may  want  to  employ  the 
questionnaire  in  Appendix  H  on  a  larger  scale  for  both  SPO 
organizations  and  personnel. 

Although  the  Suggested  or  Alternative  Model  for 
determining  PC  software  requirements  was  specifically 
developed  for  SPOs,  it  remains  to  be  tested.  Moreover,  it 
may  have  applications  for  a  number  of  other  organizations  if 
tests  prove  positive.  Thus,  other  researchers  may  wish  to 
test/investiqate  how  well  this  model  could  meet  SPO  and 
other  organization's  PC  software  requirements  needs. 


other  researchers  may  also  want  to  explore  the  area  of 
PC  software  training  within  organizations.  This  area  is 
critical  because  if  prospective  users  receive  inadequate 
training  in  how  to  use  the  acquired  PC  software  tools,  they 
will  not  know  how  to  best  integrate  them  to  support  their 
office  tasks. 

Another  area  for  future  study  is  the  role  of  the 
information  center  in  supporting  the  use  of  PC  software 
within  organizations.  These  centers  could  potentially  be 
responsible  for  conducting  PC  software  requirements 
analysis,  procurement  administration,  providing  training, 
and  application  development.  Consolidating  these  functions 
into  one  department  may  revolutionize  the  way  the  DoD 
manages  PC  software. 

Finally,  future  researchers  may  want  to  re-examine  the 
concept  of  standardization  of  PC  software  among  SPO 
organizations.  This  standardization  could  be  either  AFSC- 
wide  or  product  division-wide  where  each  organization  would 
have  uniform  PC  software  products.  Administration  of 
procurement,  training,  and  requirements  analysis  might  be 
the  responsibility  of  a  SPO  information  center  located  at 
each  product  division.  This  structure  may  reduce  training 
requirements  for  reassigned  personnel,  make  software 
purchases  cheaper  due  to  large  quantity  procurements,  and 
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still  offer  SPOs  increased  productivity  over  the  idea  of 
standardizing  PC  software  Air  Force  or  DoD-wide. 

Research  Sununarv 

This  study  was  conceived  to  explore  better  ways  of 
conducting  PC  software  requirements  analysis.  It  is  based 
on  a  survey  of  75  participants  representing  one  SPO  from 
each  of  the  five  product  divisions  within  AFSC.  Although 
limited  in  scope,  this  research  accomplished  five  major 
objectives.  First,  it  determined  the  effectiveness  of 
currently  available  PC  software  applications  used  by  SPOs. 
Second,  the  study  examined  the  current  processes  SPOs  use  to 
identify  PC  software  requirements.  Third,  it  explored  the 
methods  SPOs  currently  use  to  procure  PC  software.  Fourth, 
it  examined  the  effectiveness  of  present  PC  software 
requirements  determination  and  procurement  practices.  And, 
lastly,  this  research  aided  the  development  of  an  alterna¬ 
tive  PC  software  requirements  determination  model  tailored 
to  SPOs.  This  Suggested  or  Alternative  Model  is  based  on 
mating  SPO  mission  objectives  and  functions  with  critical 
office  tasks  necessary  to  accomplish  these  objectives  and 
functions.  It  then  investigates/selects  those  PC  software 
products  which  will  best  support  the  office  task(s).  Use  of 
this  model  should  better  able  SPOs  to  define,  justify,  and 
satisfy  PC  software  requirements. 
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Functioning  in  an  era  of  continued  manpower  reductions, 
coupled  with  a  philosophy  of  "doing  more  with  less,"  has 
prompted  the  Air  Force  to  acquire  more  PCs  in  hopes  of 
automating  various  office  tasks  for  increased  productivity. 
This  quest  for  more  productivity  is  exemplified  in  SPOs 
where  timely,  organized,  and  accurate  information  is 
essential  to  a  successful  acquisition  program.  PCs, 
although  relatively  inexpensive,  are  sophisticated 
management  tools  requiring  various  application  software 
packages  to  efficiently  and  effectively  automate  office 
tasks.  However,  the  proliferation  of  PC  software  on  the 
market  has  made  choosing  the  right  software  for  the  right 
job  a  difficult  proposition.  The  Suggested  or  Alternative 
Requirements  Determination  Model  provides  a  comprehensive 
methodology  for  assisting  SPOs  in  determining  their  PC 
software  requirements.  Better  determination  of  PC  software 
requirements  should  make  choosing  the  right  software  for  the 
right  job  an  easier  task,  thereby  resulting  in  enhanced 
mission  effectiveness. 
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Appendix  A:  Glossar 


Application  Programs  (or  Software)  -  Computer  programs 
used  to  perform  specific  user  tasks,  such  as  word 
processing,  database  management,  etc.  They  may  be 
general-purpose  or  specifically  designed  to  address  unique 
tasks  (30:6) . 

Communications-Computer  System  -  A  combination  of 
facilities,  procedures,  hardware  and  software,  transmission 
media,  and  other  resources  used  in  processing,  transmitting, 
emitting,  or  receiving  information  by  electromagnetic  or 
electronic  means  (27:6). 

Communications-Computer  Systems  Requirements  Board 
(CSRB)  -  The  corporate  body  established  at  base-level, 
MAJCOM,  and  HQ  USAF  to  validate  communications-computer 
systems  requirements  and  approve  or  disapprove  technical 
solutions  (27:6) . 

Communications-computer  Systems  Officer  (CSO)  -  At 
base-level,  the  commander  of  the  communications  unit 
responsible  for  carrying  out  base  communications-computer 
systems  responsibilities  (30:10). 

Blectronic  Bulletin  Board  -  A  system  which  connects 
users  and  a  common  host  which  is  used  to  exchange  software 
programs,  technical  information,  and  other  information  (30). 
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Information  Systems  Requirements  Analysis  (ISRA)  -  This 
stepwise  methodology  helps  organizations  identify  ways  to 
improve  their  mission  effectiveness  by  enhancing  information 
management  systems  which  in  turn  help  decrease  mission 
support  costs  and  increase  the  probability  for  mission 
success  (29:1) . 

Knowledge  Tasks  -  These  are  the  tasks  involving 
thinking,  information  processing,  and  the  formulation  of 
analyses,  procedures,  and  recommendations.  Such  tasks 
include:  communication,  planning  and  decision-making, 

diagnosis  and  problem  solving,  system  development, 
monitoring  and  control,  organizing  and  scheduling,  and 
authoring  and  presentation  (25:409). 

Operating  System  Software  -  Package  of  system  programs 
resident  in  the  computer  (like  PC-DOS,  MS-DOS,  etc.)  which 
manages  all  computer  hardware  system  functions,  like  file 
and  disk  management  and  coordinating  application  programs; 
it  provides  the  link  between  the  user  and  the  computer 
(96:4-7) . 

Personal  Computer  (PC)  -  A  specific  class  of  electronic 
hardware,  including  associated  software  and  peripherals, 
capable  of  executing  a  variety  of  software  programs.  It 
characteristically  consists  of  (at  a  minimum)  a  central 
processing  unit  (CPU)  with  random  access  memory  (RAM)  and 


read-only  memory  (POM) ,  disk  drive,  keyboard,  and  a  visual 
display  terminal  (VDT)  [25:66]. 

Public  Domain  Software  -  Software  which  has  been 
released  by  the  author  to  the  general  public  at  no  cost.  It 
is  non-copyrighted,  non-copyprotected  software  which  usually 
offers  no  support  or  guarantee  of  accuracy  (30:10), 

Requirement  -  A  need  for  a  new  or  improved  way  of 
capturing  or  processing  data,  producing  information, 
controlling  a  business  activity,  or  supporting  management. 

If  this  need  is  satisfied,  it  could  potentially  increase 
mission  success  and/or  decrease  mission  support  costs 
(88:66;  29:1). 

Requirements  Determination  -  The  process  of  using 
strategies  and  procedures  to  evaluate  management  goals/- 
objectives  and  behavior  characteristics  to  fulfill  a  user 
application  need.  It  involves  studying  the  current 
information  systems  to  discover  how  it  works  and  where 
improvements  can  be  made  (25:473-496;  88:66). 

Shareware  -  Privately  or  commercially  developed 
software  which  is  usually  distributed  free  of  charge  for 
trial  period  use.  However,  after  the  trial  period,  a  fee  is 
generally  expected  for  continued  use.  Support  is  often 
implied  or  promised  by  the  author,  but  it  is  usually  minimal 
(30:10)  . 


102 


Software  Product  -  Specifically  named  application 
programs  like  Condor,  WordPerfect  5.0,  MathCAD,  etc. 

Software  Type  -  Categories  in  which  software  products 
may  be  placed,  like  spreadsheets,  word  processors,  decision 
support  systems,  etc.  (44:7). 

Standard  Personal/Small  Computer  Contract  -  An  Air 
Force-wide  contract  used  to  procure  PC  resources  (both 
hardware  and  software)  [30:3]. 

User  -  Personnel  who  actually  use  computer  systems 
and/or  associated  products. 

User  Involvement  -  Getting  input  during  the  system 
requirements  development  process  from  the  personnel  who  use 
or  will  use  the  computer  system  and/or  associated  products. 


103 


Appendix  B :  Guide  to  Current  PC  Software 
Applications  for  SPOs 

In  this  section,  brief  ratings  of  the  various  PC  software 
products  which  a  typical  SPO  might  use  are  presented  for 
reference.  These  ratings  have  been  compiled  from  the 
leading  computer  magazines.  These  magazines  include  PC 
Magazine .  Byte .  PC  World.  Compute ! .  and  Personal  Computing. 
The  software  products  rated  are  not  meant  to  be  everything 
to  everyone.  Rather,  they  are  meant  to  give  the  prospective 
user  a  basic  starting  point  to  conduct  further  investigation 
into  these  and  other  products  available  in  the  desired 
category  which  may  be  best-suited  to  their  particular 
application  need.  Products  rated  include  word  processors, 
spreadsheets,  databases,  program  managers,  integraced 
packages,  program  information  managers,  mathematical 
packages,  decision  support  packages,  statistical  packages, 
and  graphics  packages. 

Word  Processors.  Perhaps  more  than  any  other  PC  software 
program,  a  good  word  processor  is  a  requisite  for  almost 
every  office  and  manager.  This  is  no  great  revelation  when 
one  considers  the  diversity  of  forms,  letters,  memos, 
manuscripts,  and  documents  which  are  common-place  in  today's 
office  environment.  Just  a  few  years  ago,  choosing  word 
processors  was  merely  a  question  of  style  or  preference. 

But  today,  there  are  some  clearly  top  products  which  can 
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make  your  writing  much  easier.  Granted,  because  of 
familiarity  and  custom,  it  is  difficult  to  convince  people 
to  change  word  processors  (74:45).  However,  given  the 
tremendous  capabilities  of  the  three  products  briefly 
described  below,  the  switch  may  be  easier  than  you  think. 

Microsoft's  Word  4.0  ($450)  is  rated  as  one  of  the  best 
because  of  its  breadth  and  depth  of  features.  For  starters, 
it  is  one  of  the  fastest  word  processors  around  and  has 
exceptional  formatting  features  which  include  "style  sheets" 
for  creating  reusable  page  designs  or  document  formats.  It 
also  offers  excellent  mouse  support  to  make  formatting  and 
editing  much  faster  and  such  features  as  macro  and  basic 
math  operations  and  an  outline  processor.  (Outliners 
compose  documents  in  outline  form,  and  it  also  serves  as 
brainstorming  tools  to  organize  an  argument  into  major  and 
minor  points.)  Moreover,  the  latest  version  (Version  5.0) 
has  enhanced  graphics  import  and  page-composition  features, 
along  with  an  integrated  page  preview  function  (7:99-101; 

74;  82). 

Lotus'  Manuscript  1.0  ($495),  geared  toward  engineering 
and  scientific  word  processing,  might  be  precisely  what  the 
engineering,  test,  and  perhaps  logistics  management  SPO 
departments  need.  Although  slower  and  less  easy  to  get  used 
to.  Manuscript  1.0  provides  the  features  necessary  to 
produce  a  host  of  scientific  and  technical  articles  and 
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reports.  Among  them  are  its  ability  to  depict  complex 
scientific  equations  and  the  ability  to  import  and  merge 
various  graphics  files  with  text.  The  basic  approach  used 
to  assemble  a  document  with  Manuscript  is  different  from  the 
ordinary  word  processor.  It  builds  documents  with  "blocks" 
(which  may  be  paragraphs  of  text  or  complex  tables  of 
equations).  To  do  this,  Manuscript  uses  a  top-of - the-screen 
menu  line,  pop-down  menu  boxes,  dialogue  boxes,  and  typed 
backslash  commands  much  like  Lotus'  1-2-3.  A  great  outline 
processor,  two-sided  printing,  excellent  help  features,  a 
100,000  word  dictionary,  and  macro  and  merge  capabilities 
are  just  a  few  of  its  other  features  (74;  78;  82). 

However,  WordPerfect  5.0  ($495)  by  WordPerfect 
Corporation  is  the  consensus  choice  as  the  best  all-around 
word  processor.  In  fact,  it  was  rated  by  PC  Magazine  as  the 
best  word  processor  of  1988  (11:110,130)  and  as  a  "Best  Buy" 
for  1989  by  PC  World  (7:97).  This  products  "artful 
compromise  between  word  processing  and  desktop  publishing, 
supplies  a  complete  set  of  features  for  creating  highly 
visual  documents"  (74:45).  It  offers  all  of  the  features 
outlined  for  Microsoft's  Word  4.0  (except  mouse  support), 
including  the  ability  to  combine  text  and  graphics  (with  the 
ability  to  rotate  and  resize),  an  undelete  feature,  superb 
help  features,  document  summary  page,  automatic  document 
backup  control,  a  preview  function,  and  the  ability  to  read 
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and  write  different  file  types  like  ASCII,  Wordstar,  Multi- 
Mate,  etc.  (7:97-98).  As  for  portability,  no  word  processor 
is  better  as  it  runs  on  a  number  of  machines,  including  MS- 
DOS,  Apple  II  series,  minicomputers,  Macintosh,  and  IBM 
mainframes.  And  for  user  convenience,  it  even  has  a  toll- 
free  service  line  (41;  78;  74;  82). 

Spreadsheets .  These  allow  the  user  to  process  and 
analyze  information  by  utilizing  the  computer's  ability  to 
calculate  and  display  data  in  the  form  of  numbers.  They 
have  been  adapted  for  forecasting,  modeling,  and  providing 
business  reports  (63:69;  78:63).  Although  every  spreadsheet 
can  crunch  a  column  of  numbers,  they  each  are  unique  in 
terms  of  performance  and  features.  Lotus'  1-2-3  has  been  at 
the  top  of  the  spreadsheet  market  for  so  long  that  choosing 
a  spreadsheet  has  been  a  very  easy  decision.  However,  as 
Lisa  Kleinman  (a  software  analyst  for  Personal  Computing 
magazine)  writes,  "Suddenly  it’s  more  like  buying  a  word 
processor:  There's  a  strong  leader,  but  lots  of  other 

attractive  choices  [as  well]"  (53:49).  The  four  products 
discussed  below  should  help  users  decide  whether  they  should 
make  a  change. 

Microsoft's  Excel  1.0  ($495)  is  highly  rated  due  to  its 
myriad  of  features  and  great  versatility.  This  easy  to  use 
spreadsheet  has  131  built-in  functions,  automatically 
recalculates  sensitivity  analysis  tables,  and  comfortably 


handles  multivariate  and  logarithmic  regression.  Excel  also 
possesses  true  presentation-quality  graphics,  file  linking, 
an  undo  command,  and  the  ability  to  store  macros  with  their 
individual  spreadsheets.  Nonetheless,  for  such  outstanding 
performance,  there  is  a  tradeof f--speed .  Excel  is  rated  one 
of  the  slowest  spreadsheets  on  the  market,  but  improvements 
are  in  the  works  (4:141-143,156;  53:49;  63:72). 

Borland  International's  Quattro  ($248)  gets  a  "Top  Rated" 
evaluation  from  Personal  Computing  magazine  (Sep  ’88) 
because  of  its  all-around  performance  and  value  (19:143). 
This  spreadsheet  offers  both  speed  and  an  abundance  of 
features  to  please  almost  everyone.  With  a  price  tag  half 
that  of  Lotus'  1-2-3,  Quattro  is  attracting  a  lot  of 
corporate  management  attention  (19:143;  86:72).  It  has  the 
ability  to  import  and  export  1-2-3  files  and  has  a  command 
structure  much  like  1-2-3's.  However,  its  pull-down  menus 
are  more  simple  to  read  and  interpret  than  1-2-3' s.  Some  of 
its  redeeming  features  are:  1)  its  10  graph  types,  2)  its 
100  mathematical  functions,  including  regression  analysis, 
frequency  distribution,  and  sensitivity  analysis  capability, 
3)  easy  macro  debugging,  4)  Turner  Hall's  popular  SQZ ! 
utility  to  automatically  compress  and  expand  files  for  more 
efficient  disk  space  utilization,  and  5)  file  linking  and 
multiple  windows  to  come  in  its  next  version  (19:145-147; 
53:49)  . 
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If  speed  and  low  cost  are  premium,  then  Paperback 
Software  International's  VP~Planner  Plus  (Version  2)  is  the 
obvious  choice.  It  retails  for  a  low  $180,  but  earned  a 
"Top  Rated"  billing  from  Personal  Computing  magazine 
(Sep  ’88)  for  its  speed  and  versatility  (4:147-149;  53:49). 
VP-Planner  Plus  is  1-2-3  compatible  with  menus  following  the 
1-2-3  convention.  Some  of  its  best  features  include  word 
processing,  box  and  line  drawing,  file  linking,  a  powerful 
multi-dimensional  database,  and  an  undo  command  with  a  60K 
buffer.  And,  unlike  other  spreadsheets,  it  does  not  have  to 
wait  for  a  recalculation  to  finish  before  entering  other 
entries  or  commands. 

Nevertheless,  Lotus'  1-2-3  is  the  market  leader  to  which 
all  other  spreadsheets  are  compared,  garnering  almost  70 
percent  of  all  spreadsheet  sales  in  1988  (4:130,139;  86:73). 
This  year  (1989),  Lotus  introduced  two  new  versions  of 
1-2-3:  Releases  2.2  and  3.0.  Release  2.2  is  a  smaller 
version  of  3.0.  Release  2.2  runs  only  with  DOS  and  has 
enhanced  graphics,  file  linking,  search  and  replace,  a 
built-in  macro  learn  mode  and  superb  macro  capability,  and 
network  support.  Release  3.0  will  only  work  with  PCs  that 
have  at  least  one  megabyte  of  random  access  memory  (RAM) . 
Besides  the  size  of  3.0,  its  best  features  are  three- 
dimensional  worksheets  (i.e.,  rows,  columns,  ard  pages),  and 
excellent  graphics  with  a  choice  of  eight  fonts.  In  fa^t. 
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Release  3.0  gives  the  capability  to  view  a  graph  alongside 
its  accompanying  worksheet  and  reflects  changes  to  data 
automatically  in  the  graph  (53:74). 

Database  Managers.  In  recent  years,  database  management 
users  have  become  much  more  demanding  of  their  database 
management  systems  (DBMS) .  Users  today  want  "programming 
clout  to  create  sophisticated  applications,  as  well  as 
advanced  querying  and  reporting  tools  they  can  master 
without  memorizing  a  manual"  (60:118).  As  a  result,  the  age 
of  the  relational  database  has  dawned,  while  the  popularity 
of  the  flat- file  database  is  beginning  to  fade.  A  flat-file 
database  or  file  managers  (as  they  are  now  called)  organizes 
data  into  "simple  two-dimensional  tables  that  resemble 
spreadsheets  [or  paper  formsj."  The  major  disadvantage  of 
file  managers  is  they  only  permit  the  user  to  work  with  one 
file  at  a  time,  thus  users  must  close  the  first  file  before 
viewing  another.  Likewise,  data  from  multiple  files  can  not 
be  pulled  into  one  report  (92:77),  File  managers  are 
generally  associated  with  typical  office  administrative 
tasks  like  recording  and  filing  information.  Although  not 
specifically  reviewed,  the  best  file  managers  include  PFS : 
Professional  File,  Reflex  1.14,  and  Q&A  3.0  (rated  the  best 
in  1988  by  PC  Magazine)  [41:110;  92:77-82]. 

On  the  other  hand,  relational  databases  are  based  on  a 
set  of  tables  which  represent  unique  entities  or  records 


which  are  linked  by  a  common  field.  In  this  manner,  data 
can  be  pulled  from  other  files  to  generate  new  files  for 
viewing,  editing,  calculating,  or  reporting  {25:123-125; 
92:84).  It  also  makes  updating  records  easier  since  updates 
made  to  parent  records  also  update  the  child  records 
(60:122).  Reviewed  below  are  four  of  the  best  relational 
database  managers. 

DataBase  4.0  ($700)  from  DataBase  International  has 
become  very  popular  in  many  corporations  because  users  can 
design  their  own  applications  by  following  easy  to  use  menus 
instead  of  writing  program  code.  However,  for  the  serious 
developer,  DataBase  falls  far  short.  It  also  lacks  the 
industry  standard  structured  query  language  (SQL)  and  the 
new  query-by-example  (QBE)  system  which  makes  command  line 
querying  a  thing  of  the  past.  Nonetheless,  DataBase  offers 
excellent  capability  for  the  beginning  user  (19:52;  18:182- 
183;  60:126-128) . 

A  few  years  ago,  R:base  ($725)  from  Microrim  took  the  PC 
relational  database  market  by  storm  when  it  introduced  a 
dynamic  command  language  and  a  very  highly  touted  appli¬ 
cation  generator  (18:188;  60:118,125-126;  92:86).  A  "Top 
Rated"  product  by  Personal  Computing  magazine  in  November 
1988  (18:182-183),  it  is  still  one  of  the  best  database 
managers  for  the  avid  programmer.  It  has  a  variety  of 
modules  and  features.  Among  the  modules  are:  1)  a 
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Definition  Express  module  to  construct  a  network  of  complex 
linked  tables,  including  a  Rules  submodule  (which  allows 
automatic  validation  of  data  entries  and  a  Views  submodule 
(which  combines  as  many  as  five  tables  of  related  data) , 

2)  a  Forms  Express  module  to  design  sophisticated  windows 
for  adding,  updating,  and  deleting  data  from  up  to  five 
tables  at  once,  3)  a  Reports  Express  module  which  organizes 
data  into  report  form,  and  4)  an  Application  Express  module 
to  construct  personal  applications,  like  help  screens, 
menus,  data-entry  forms,  reports,  etc.  by  simply  following 
the  prompts  (92:86).  Some  of  its  more  impressive  features 
include  superb  spreadsheet-like  financial  analysis 
capability,  cross-tabulation,  and  impressive  speed,  network 
(only  one  package  is  required  to  serve  multiple  users) ,  and 
SQL  support  (60:125-126;  92:86).  Nevertheless,  Rtbase  is 
not  a  very  user-friendly  database  for  the  casual  user,  it  is 
targeted  for  the  serious  programmer  with  a  good  knowledge  of 
command  syntax  (60:125-126). 

Borland  International's  Paradox  3.0  ($725),  another  "Top 
Rated"  product  by  Personal  Computing  magazine  for  1988, 
possesses  super-fast  speed  and  overall  superior  performance 
for  users  who  do  not  like  or  need  much  programming 
flexibility  (18:182;  60:120).  However,  the  programming  it 
does  offer  is  fast  and  very  easy  to  learn  although  it  can 
not  rival  that  of  R:base  or  Dbase  IV  (60:120).  Some  of  its 
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most  redeeming  features  are  built-in  graphics  which  lets  the 
user  create  pie,  bar,  line,  and  stacked  bar  charts  effort¬ 
lessly;  excellent  screen  and  report  generators;  cross¬ 
tabulation  statistics;  superb  querying  with  QBE;  and  a  new 
operator  called  SET  which  permits  fine  relational  algebra 
capability.  But  a  major  drawback  is  Paradox's  lack  of  SQL 
which  may  drive  away  potential  users  in  spite  of  its 
otherwise  smooth  operations  (60:120-125;  92:87-88). 

Ashton  Tate's  Dbase  has  been  to  database  management  what 
Lotus'  1-2-3  has  been  to  spreadsheets — the  market  leader. 
Dbase  IV  is  no  exception;  it  has  recaptured  the  lead  for  PC 
database  managers  with  this  improvement  over  Dbase  III+. 
Perhaps  the  biggest  improvements  have  been  its  increased 
user-friendliness  and  application  development  (60:119; 
85:98).  Its  Control  Center  is  one  of  the  best  as  it 
"automatically  catalogs  all  queries,  labels,  forms,  and 

I 

reports  and  opens  them  with  their  related  database" 

(60:119).  Dbase  IV  touts  a  menu-driven  application 
generator  which  surpasses  its  rivals  and  should  please  both 
the  avid  programmer  and  the  casual  user.  Programmers  can 
write  complex  programs  by  simply  linking  forms,  labels,  and 
reports.  They  may  then  be  edited  with  its  first-rate 
editor,  and  it  also  has  a  compiler  which  automatically 
catches  syntax  errors  before  the  program  is  run.  Dbase  IV 
also  offers  excellent  data  entry  screen  generators  and  top- 
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notch  report  generation  capability.  Although  it  provides 
for  QBE  and  SQL,  Dbase  IV  is  slow  in  conducting  these 
queries  (in  relation  to  R:base  and  Paradox).  As  well,  the 
SQL  system  is  awkward  which  Dbase  IV  (Version  1.1) 
supposedly  has  fixed.  Still,  it  is  the  database  manager  to 
beat  because  of  its  superior  development  tools  and  user- 
frienaliness  (60:119-120). 

Integrated  Packages.  As  one  analyst  notes,  "Integrated 
software  is  the  computer  world’s  answer  to  the  Renaissance 
man — do  everything  with  competence,  if  nothing  with 
excellence."  An  integrated  package  gives  the  user  an  all- 
in-one  collection  of  software  applications.  These 
application  tools  typically  include  a  word  processor, 
spreadsheet,  database,  communications,  and  graphics. 
Integrated  software  offers  the  user  simplicity  (ease  of  use) 
and  compatibility  between  different  application  files 
(1:30).  Products  reviewed  fall  into  two  categories:  those 
low-end  packages  costing  less  than  $300  and  those  on  the 
high-end  costing  over  $300. 

In  the  low-end  category,  two  packages  stand  out: 
AlphaWorks  1.0  and  Microsoft  Works  1.05.  Both  earned  "Best 
Buy"  ratings  from  PC  World  magazine  (Apr  '89)  [34:96,99]. 

AlphaWorks  ($195)  from  Alpha  Software  Corporation  uses 
many  standard  file  formats  which  makes  it  easy  to  swap  files 
between  users  with  other  applications.  This  program  allows 
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the  user  to  keep  up  to  29  files  open  (9  each  in  word 
processing,  database,  and  spreadsheet  and  2  in  communi¬ 
cations)  and  toggle  between  them.  Word  processing  is  simple 
and  has  automatic  reformatting,  rapid  search,  and  a  120,000 
word  thesaurus.  However,  it  only  permits  ASCII  files  to  be 
imported  and  exported.  The  database  is  very  adaptable  using 
the  standard  Dbase.dbf  format  and  supplies  an  unlimited 
number  of  records.  The  spreadsheet  has  75  functions  (more 
than  1-2-3)  and  uses  the  1-2-3. WKS  format.  It  also  has  more 
user-friendly  pop-down  menus.  AlphaWorks  has  integrated 
graphics  with  five  chart  types  which  are  easy  to  use  and  a 
solid  communications  package  (34:95-98). 

"An  impressive  piece  of  software  artistry,  Microsoft 
Works,"  according  to  Dennis  Dykstra  (analyst  for  PC  World 
magazine),  "sports  an  elegant  interface,  a  first-class 
spreadsheet,  great  graphics,  and  mouse  support."  Retailing 
for  $149,  it  comes  with  an  excellent  manual  and  magnificent 
tutorials.  Microsoft  Works  1.05  has  an  array  of  word 
processing  features  and  a  very  good  database.  unfor¬ 
tunately,  neither  the  spreadsheet  or  database  use  industry- 
standard  file  formats.  It  does  have  an  outstanding 
spreadsheet  module  which  reads  and  writes  both  1-2-3' s  .WKS 
and  .WKl  files.  The  spreadsheet  also  automatically 
translates  1-2-3  formulas  when  1-2-3  files  are  loaded.  In 
addition,  the  integrated  graphics  module  links  charts  to 
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worksheets  which  when  updated  also  update  the  charts.  The 
graphics  module  also  supplies  a  variety  of  text  fonts  and 
sizes.  While  the  communications  module  is  limited, 

Microsoft  Works  1.05  ranks  as  the  best  all-around  choice 
(34:99-100) . 

On  the  upper-end  of  the  price  spectrum,  there  are 
essentially  two  industry  leaders:  Symphony  and  Enable. 

Both  of  these  packages  retail  for  $695  and  offer  the  same 
basic  features,  plus  some  enhanced  capabilities. 

However,  there  is  an  important  message  to  be  heard  in 
reference  to  integrated  packages.  That  message  is  that 
although  integrated  packages  offer  all-in-one  convenience, 
they  can  not  be  everything  to  everyone.  By  their  nature, 
they  typically  can  not  perform  tasks  to  the  level  of 
expertise  required  by  most  users  who  use  specific  PC 
software  application  packages. 

Project  Management  Software.  Until  very  recently,  PC 
project  management  software  have  suffered  from  being  either 
too  difficult  to  use  or  lacking  functionality.  However, 
today  there  are  some  very  capable  programs  costing  less  than 
$600  which  can  assist  the  program  manager  in  imposing 
structure  on  the  complex  interaction  of  time,  resources,  and 
activities  (40:177,187).  Since  virtually  every  project 
contains  the  three  main  phases  of  planning,  implementation, 
and  evaluation,  project  management  software  aims  to  address 
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these  phases  by  helping  break  down  a  project  into  its 
component  parts  (which  is  usually  necessary  for  good 
management  control)  [39:90].  These  programs  offer  excellent 
ways  to  track  and  analyze  information  for  a  project 
(40:177).  Project  management  software  is  particularly 
suited  to  manipulating  date  and  time  inforonation  in  devising 
a  project  schedule.  They  integrate  such  management  science 
techniques  like  program  evaluation  and  review  technique 
(PERT)  and  critical  path  method  (CPM)  to  determine  a 
project's  estimated  completion  time,  along  with  the  various 
task  duration  estimates  and  the  most  schedule  constraining 
or  critical  tasks.  Using  charts  and  graphs  (like  PERT  and 
Gantt) ,  project  managers  allow  the  user  to  visually  monitor 
the  progress  and  costs  of  a  project.  Although  these 
programs  obviously  can  not  take  the  place  of  sound  program 
management  practices,  they  can  be  a  big  help  by  arranging 
tasks  by  priority  and  within  a  specified  time  period.  As 
Harvey  Levine,  chairman  of  the  board  of  the  Project 
Management  Institute  in  Drexel  Hill,  Pa.  (a  professional 
society  for  program  managers)  states,  "This  kind  of  program 
is  so  inexpensive  today  that  I  don’t  know  why  anyone  who 
needs  to  control  a  schedule  or  costs  would  use  something 
else"  (39:90).  The  two  programs  presented  below-- 
SuperProject  Plus  and  Time  Line — should  provide  excellent 
support  to  the  average  program  manager. 
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SuperProject  Plus  (Version  3.0)  listed  at  $395  by 
Computer  Associates  International  possesses  a  host  of 
features.  Among  them  are  an  outliner,  a  work  breakdown 
structure  (WBS)  chart,  a  resource  histogram  for  resource 
management,  multiple  report  types,  and  Gantt  and  CPM  chart 
capability.  This  program,  rated  an  "Editor's  Choice"  by  PC 
Magazine  in  1988,  also  has  two  skill  levels  allowing 
beginners  to  take  advantage  of  this  tremendous  capability  as 
well  as  skilled  program  managers.  In  addition,  if  the 
manager  desires  macro  capability  and  the  ability  to  import 
files  from  other  programs,  an  enhanced  version  is  available 
called  SuperProject  Expert  ($695) .  It  also  has  network 
capability,  plotter  support,  additional  report  types,  and 
PERT  (which  addresses  the  uncertainty  in  a  project  by  using 
probability  to  assign  each  task  an  optimistic,  pessimistic, 
and  most-likely  time  duration  (40:224,187-188). 

Another  "Editor's  Choice"  award  from  PC  Magazine  in  1987 
and  1988  is  Symantec's  Time  Line  (Version  3.0)  at  $595. 

This  user-friendly  package  boasts  an  outliner,  superb  report 
types,  excellent  note-taking  capability,  27  macro-like 
shortcut  command  keys,  macro  programmability,  a  resource 
histogram,  a  WBS  chart,  and  Gantt  and  CPM  charts,  and  an 
undo/redo  command  which  is  very  useful  for  sensitivity 
analysis  (40:222-225). 
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There  are  also  a  number  of  other  project  management 
programs  available  (like  Harvard  Total  Project  Manager, 
Microsoft  Project,  etc.)  which  may  be  well-suited  to  fulfill 
the  needs  of  a  manager.  Before  selecting  any  of  these 
project  management  packages,  potential  users  may  well  be 
advised  to  consider  the  tips  outlined  in  Table  12.  Still, 
these  programs  may  provide  invaluable  assistance  to  the 
average  inundated  program  manager. 

Personal  Information  Managers.  Because  this  area  of  PC 
software  applications  is  so  new  (early  1988),  many  managers 
may  not  be  aware  of  this  application.  Personal  information 
managers  (PIMs)  are  designed  to  allow  users  to  easily 
retrieve,  analyze,  and  cross-reference  data — both  words  and 
numbers.  Personal  information  consists  of  those  random 
pieces  of  information  which  cross  the  typical  manager's  desk 
every  day,  like  notes  scribbled  on  a  scratch  pad,  phone 
messages,  annotations  made  on  various  documents,  lists  of 
things  to  do  that  day,  important  phone  numbers  to  remember, 
etc.  (17:92;  93:282).  PIMs  are  designed  to  organize  these 
random  bits  of  daily  information  which  do  not  easily  fit 
into  a  rigid  format  like  databases  or  word  processors 
(17:92;  77:105).  Lotus  Corporation,  the  first  to  take 
advantage  of  this  management  need,  lists  three  essential 
criteria  for  PIMs: 

1.  They  should  be  specifically  designed  to 

handle  random,  free- form  entries  consisting 
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Table  12.  Tips  for  Selecting  a  Project  Manager  (39:93) 


1.  If  your  project  is  simple  and  involves  little 
scheduling,  or  if  only  a  few  people  will  be 
involved,  then  perhaps  a  traditional  program  like 
a  word  processor,  outliner,  spreadsheet,  or 
database  might  be  sufficient- 

2.  Use  programs  that  handle  planning  only  if  you  are 
just  going  to  develop  a  blueprint  for  a  project. 

3.  To  monitor  a  project,  program  management  software 
should  compare  your  target  plan  to  the  actual  time 
and  costs  expended.  Likewise,  the  program  should 
not  overwrite  target  dates  or  costs  when  you  make 
adjustments  to  the  cost  and/or  duration  of 
individual  tasks  in  a  project.  The  program  should 
do  this  at  any  point  in  a  project,  not  just  at  the 
end. 

4.  Look  for  good  hard-copy  tabular  and  graphics 
reporting  features.  Reports  can  be  important  tools 
when  dealing  with  top  management  or  clients.  The 
ability  to  link  the  management  program  to  a  plotter 
for  Gantt  and  PERT  charts  is  a  nice  plus — it  makes 
reports  look  that  much  better. 

5.  If  you  need  to  do  special  analytical  tasks  on 
project  costs,  or  prepare  reports  which  only  a 
database  can  produce,  get  a  project  manager  that 
can  share  data  with  other  programs — preferably  in 
their  original  formats. 

6.  Make  sure  the  program  you  choose  is  straightforward 
and  easy  to  understand.  A  complicated  program  may 
just  sit  on  the  shelf. 


of  short  pieces  of  text  (words,  phrases,  sentences, 
or  lists) . 

2.  They  should  be  all-purpose  tools  with  the 

flexibility  to  manage  anything  from  lists  of 
things  to  do  to  brainstorming  sessions. 
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3.  They  should  be  able  to  link  various 

unstructured  bits  of  information,  thereby 
enabling  the  manager  to  establish  working 
relationships  between  otherwise  separate 
items  (77 : 106) . 

Surprisingly,  of  the  approximately  25  PIMs  on  the  market 
today,  only  4  were  judged  by  Personal  Computing  magazine 
(Jul  '89)  as  meeting  this  criteria,  they  are:  Info-XL  by 
Valor  Software,  Polaris  Software’s  PackRat,  Grandview  by 
Symantec  Corporation,  and  Lotus’  Agenda  (77:106). 

Info-XL  uses  a  very  pragmatic  approach  to  information 
management.  It  uses  an  outline  as  its  primary  organizing 
structure,  but  it  uses  several  other  structures  as  well.  In 
fact,  Info-XL  uses  "six  distinct,  on-screen  windows  to 
manage  and  relate  information."  The  Manager  window  allows 
the  user  to  enter  text  as  headlines  and  subheadlines;  the 
Records  window  is  used  to  enter  database  information,  like 
names  and  addresses;  the  Comments  window  can  handle  pieces 
of  completely  unstructured  text,  like  notes;  the  Daily 
Schedule  and  Monthly  Calendar  permit  outlined  data  items  to 
be  listed  in  chronological  order  with  a  time  and  date;  and 
the  Search  window  gives  the  manager  the  ability  to  extract 
all  entries  containing  a  specified  word  or  phrase  (77:109). 

PackRat  functions  superbly  in  the  environment  of 
Microsoft  Windows,  although  it  does  work  outside  these 
confines.  This  is  an  important  point  for  the  manager  who 
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already  uses  f/indows  because  if  he  does,  then  the  obvious 
choice  for  a  PIM  is  PackRat.  This  program  houses  seven 
excellent  utilities.  Among  them  are  a  Phone  Book  equipped 
with  auto  dialing  and  label  printing;  a  Phone  Log  with  ample 
note  space;  a  Task  (to  do)  List  which  allows  priority  and 
status  setting;  an  Agenda  (appointment  schedule)  complete 
with  visual  and  aural  reminders;  an  Expense  Log  that  has 
unlimited  categories  and  summary  totals;  a  Disk  File  Log 
equipped  with  notes  on  data  files  and  the  ability  to  load 
applications;  and  Index  Cards  for  taking  notes  on 
miscellaneous  text  and  graphics.  PackRat  also  keeps  an  on¬ 
screen  calendar  to  display  information  from  any  of  its 
utilities  by  specifying  a  date  or  range  of  dates  (e.g.,  show 
all  to-do  items  for  the  week  from  the  Task  List  utility) . 

As  well,  it  allows  the  manager  to  link  and  retrieve 
information  by  selecting  key  words  and  by  attaching  an  item 
from  one  utility  to  another  utility  (17:170;  77:111). 

Grandview  is  another  PIM  which  is  structured  around  an 
outline.  But  beware;  it  is  so  outline  structured  that  it 
may  not  be  a  wise  choice  for  managers  with  a  different 
cognitive  style  since  it  forces  the  manager  to  think  where 
the  next  item  should  fit  before  it  is  actually  entered 
(17:170).  Nonetheless,  Grandview  is  an  excellent  product. 
Text  is  entered  as  headlines  and  subheadlines  in  familiar 
outline  form.  The  word  processing  capability  is  arguably 
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the  best  of  all  the  PIMs;  it  has  a  text  editor,  spell 
checker,  and  even  provides  multiple  printer  font  support. 
Grandview  uses  categories  to  link  separate  entries,  like 
categorizi-'.g  by  date  and  priority.  This  PIM  seems  parti¬ 
cularly  suited  to  managers  who  use  tidbits  of  information  as 
seeds  for  greater  things  like  memos,  letters,  briefings, 
reports,  etc.  (77:108-109). 

Agenda  has  been  billed  as  the  "quintessential  PIM"  by 
Personal  Computing  magazine  and  was  selected  as  one  of  the 
"Best  Products  of  1988"  by  PC  Magazine  (77:106;  11:130). 

This  is  an  "open-ended,  highly  adaptable  program  with  the 
power  to  connect  entries  as  other  PIMs  cannot."  It  is  so 
flexible  because  it  has  very  little  apparent  structure. 

Data  items  are  entered  under  section  headings  in  any  format 
the  manager  desires;  syntax  rules  are  non-existent.  Agenda 
provides  real  power  in  its  ability  to  link  these  items  in 
categories  which  the  user  defines.  Using  the  Condition 
function,  managers  can  customize  Agenda  to  automatically 
assign  items  to  categories,  given  they  meet  the  pre-defined 
criteria  (like  containing  a  certain  word  or  belonging  to 
another  category) .  The  Action  function  gives  the  manager 
the  opportunity  to  make  modifications  when  assigning  new 
items  to  existing  categories.  This  function  also  enables 
the  user  to  conduct  operations  like  deleting  and  exporting 
files.  Agenda  also  offers  extensive  macro  capability  and 


several  artificial  intelligence  (AI)  features  to  make 
matching  items  to  categories  much  simpler.  For  instance,  it 
can  be  programmed  to  recognize  synonyms  like  "Chuck"  for 
"Charles"  or  "PM"  for  "program  manager,"  and  it  can  also 
translate  such  words  as  "tomorrow"  and  "end  of  the  week" 
into  their  proper  dates  for  assigning  items  to  time-related 
categories  (77:106-107).  Although  Agenda  is  a  PIM  with 
exceptional  capabilities,  learning  to  use  this  tool  can  be 
quite  challenging,  making  it  a  tough  choice  for  managers 
with  little  time  for  learning  a  new  product.  However,  once 
it  has  been  learned.  Agenda  is  a  super  PIM  which  can  be 
modified  to  suit  individual  manager’s  needs  (17:170; 

77:107) . 

Mathematical  Packages.  "Ten  years  ago,"  according  to 
Barry  Simon,  "machine-driven  scientific  calculation  was 
neatly  split  into  two  phases:  serious  number  crunching  on  a 
mainframe  and  simple  calculations  on  a  hand-held 
calculator."  However,  today  the  PC  has  filled  this  middle 
ground  void  by  making  it  possible  for  mathematical  packages 
to  perform  either  or  both  of  these  roles.  These  packages 
can  be  easily  divided  into  two  groups:  1)  non-programmable 
packages  intended  for  calculating  and  modeling  and 
2)  programmable  packages  (which  possess  full-fledged 
mathematical  languages)  intended  for  tasks  requiring  custom 
programs  which  m.ight  be  written  in  Fortran,  Turbo  Pascal,  C, 
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etc.  Natural  scientists  and  engineers,  along  with  some 
social  scientists,  programmers,  and  financial  model  builders 
find  tools  such  as  these  invaluable  (91:289-290). 

Although  there  are  quite  a  number  of  programs  a  SPO 
engineering  department  may  find  beneficial,  only  two  of  the 
best  (one  programmable  and  one  non-programmable)  are 
reviewed  here. 

PC  Magazine  rates  Microsoft's  MatbCAD  ($295)  as  the  best 
of  the  mathematical  software  programs  without  extensive 
programming  language.  This  program  is  very  easy  to  learn 
and  is  well-suited  to  the  everyday  needs  of  engineers, 
scientists,  and  mathematicians.  It  lets  the  user  write 
equations  using  familiar  mathematical  notation  (which  are 
immediately  calculated)  and  integrate  text  (to  explain  or 
summarize)  anywhere  with  ease  in  a  "what-you-see-is-what- 
you-get"  format.  MathCAD  even  plots  the  mathematical 
functions  instantly  on  the  computer  screen.  The  program  is 
very  comprehensive,  handling  an  assortment  of  operations 
li)«e  matrices,  simultaneous  equations,  automatic  unit 
conversion,  real  and  complex  numbers,  and  a  host  of  trigo¬ 
nometric  and  statistical  functions.  It  also  automatically 
flags  errors  and  supports  a  variety  of  printers  (91:290- 
295,308) . 

For  programs  with  extensive  programming  language,  the 
choice  is  less  clear  among  such  programs  as  Asyst,  MathGraf, 
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Matlab,  TK! Solver  Plus,  Curve,  and  Gauss.  Nonetheless, 

Gauss  by  Aptech  Systems  earned  "Editor's  Choice"  honors  from 
PC  Magazine  in  March  1989.  It  offers  impressive  speed, 
which  is  key  for  performing  calculations,  in  an  easy  user 
interface  and  an  excellent  programming  language.  Gauss  also 
has  quick  graphics  along  with  superior  presentation-quality 
graphics  (91:308). 

Decision  Support  Packages.  This  category  of  PC  software 
may  prove  beneficial  for  every  SPO  where  a  number  of 
decisions  are  made  almost  daily.  Decision  support  software 
is  designed  to  help  managers  provide  structure  to  complex 
problems  by  breaking  them  into  manageable  portions.  These 
systems  do  not  actually  make  decisions,  but  they  provide  a 
tool  for  evaluating  alternatives.  Selection  of  the  most 
appropriate  alternative  is  left  to  the  manager  (2:1).  Two 
of  these  products  are  reviewed  for  this  study  as  an  intro¬ 
duction  to  decision  support  software  for  the  PC.  They  are 
Expert  Choice  and  Decision  Aide  which  both  retail  for  $495. 
These  products  were  reviewed  by  the  researcher  on  a  personal 
basis  and  in  an  academic  setting. 

Expert  Choice  allows  the  user  to  develop  a  hierarchy  of 
criteria  to  give  the  appropriate  consideration  to  each 
aspect  of  the  decision  process,  along  with  assessing  the 
risk  level.  It  is  based  on  the  Analytic  Hierarchy  Process 
developed  at  the  Wharton  School  of  Business  and  allows  users 
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to  prioritize  factors  and  criteria  based  on  qualitative 
(verbal  judgments)  and  quantitative  assessments  (38). 

Expert  Choice  also  uses  information  screens  for  note  ta)cing 
and  assessing  data  from  a  spreadsheet  or  word  processor.  In 
addition,  it  gives  the  user  the  capability  to  fully  document 
the  decision  model  with  one  command  (37).  This  model  has 
also  been  used  very  successfully  in  an  academic  environment 
to  evaluate  proposals  for  source  selection. 

Decision  Aide  offers  the  same  capability  as  Expert 
Choice  to  develop  a  hierarchy  of  qualitative  and  quanti¬ 
tative  assessment  criteria.  The  program  is  segmented  into 
eight  separate  modules;  1)  Plan  Your  Decision,  2)  State 
Decision,  3)  Establish  Criteria,  4)  Generate  Alternatives, 

5)  Evaluate  Alternatives,  6)  Assess  Adverse  Consequences, 

7)  Make  Choice,  and  8)  Print  Report.  There  is  flexibility 
to  use  as  many  or  as  few  of  these  modules  as  required  to 
support  a  decision  analysis  (26) . 

Statistical  Packages.  Unlike  most  general  PC 
applications,  such  as  word  processors,  databases, 
spreadsheets,  etc.  which  use  similar  conceptual  frameworks, 
statistical  packages  use  an  array  of  frameworks.  As  Robin 
Raskin  (a  statistical  analyst  for  PC  Magazine)  states,  "... 
you'll  be  hard  pressed  to  find  any  two  that  are  alike  in 
their  'look  and  feel'  or  methodology."  Consequently,  users 
must  evaluate  the  myriad  of  statistical  packages  on  their 
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own.  With  over  200  commercial  statistical  products  and 
several  hundred  shareware  programs,  choosing  the  right 
package  can  be  a  harrowing  experience.  For  purposes  of  this 
review,  statistical  packages  were  broken  into  two  cate¬ 
gories:  basic  and  advanced.  Basic  packages  are  those 

handling  a  variety  of  basic  stacistical  procedures,  like 
descriptive  statistics,  linear  regression,  analysis  of 
variance,  discriminant  analysis,  cross-tabs,  and  non- 
parametric  tests.  Those  labeled  as  advanced  packages  are 
characterized  by  big,  comprehensive  programs  which  have  a 
number  of  additional  statistical  procedures,  along  with  data 
handling  and  programming  capability  (80:103-104). 

In  the  category  of  basic  packages,  PC  Magazine  chose  two 
products  for  their  coveted  "Editor's  Choice"  award.  Minitab 
Statistical  Softtrare  ($695)  and  Statistix  ($169)  .  Both  of 
these  tools  import  and  export  ASCII  files,  diagram 
histograms  and  scatter  plots,  and  perform  descriptive 
statistics  (mean,  variance,  etc.),  linear  regression,  and 
analysis  of  variance.  Individually,  Minitab  Statistical 
Software  offers  simplicity  in  a  more-than-adequate  command 
language  and  good  macro  capability.  Statistix  provides  75 
of  the  most  commonly  used  statistical  functions  in  a  fairly 
flexible  menu-driven  system.  It  also  has  good  data  handling 
capability  (80:169-199). 
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For  advanced  statistical  programs,  three  packages  were 
chosen  by  PC  Magazine  as  "Editor’s  Choice"  recipients.  They 
were  SPSS/PC+,  Systat,  and  Statgraphics.  All  of  these 
packages  have  a  programming  language  making  it  possible  to 
design  a  complex  statistical  procedure.  These  programs  are 
faster  and  can  handle  larger  data  sets  than  the  basic 
packages.  They  also  have  higher-level  operations  like 
multivariate  analysis,  time-series  analysis,  factor 
analysis,  and  non-linear  regression,  along  with  sophis¬ 
ticated  data  editing,  handling  capabilities,  and  diagnostic 
routines  for  testing  underlying  assumptions  (80:121). 

SPSS/PC+  ($795)  is  the  offspring  of  the  popular 
mainframe  version  of  SPSS.  Although  it  does  not  fully 
emulate  the  mainframe  version,  SPSS/PC+  does  provide  a 
powerful  substitute.  Interactive  menus  and  interactive 
execution  make  this  a  very  manageable  and  productive 
program.  SPS5/PC+  produces  excellent  charts  and  tables,  but 
is  lacking  when  it  comes  to  data  management  and  regression 
vith  analysis  of  variance  (ANOVA)  [80:161]. 

On  the  other  hand,  Systat  ($795)  performs  well  with 
linear  models  like  ANOVA  regression  and  has  a  very  user- 
friendly,  powerful  command  language  (partly  because  it  was 
developed  on  a  PC)  and  terrific  graphics.  However,  Systat' s 
performance  lacks  in  the  cross-tabs  area  (80:161). 
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Statgrapbics  ($895)  was  developed  on  a  PC  specifically 
for  PC  users.  As  a  result,  it  has  a  terrific  user  interface 
and  command  structure  with  powerful  menus.  It  also  has 
superior  graphics  capability  (80:161). 

When  it  comes  to  statistical  PC  software,  it  is 
important  to  realize  that  no  one  pacltage  will  meet  the 
user's  every  need.  One  package  may  have  a  superior  fort6  in 
one  required  area  and  be  very  poor  in  another.  The  key  is 
to  seek  those  packages  which  will  provide  the  best  coverage 
of  procedures  the  user  deems  most  critical  (80:161). 

Graphics  Software  Packages.  This  area  of  PC  software  is 
common  to  virtually  every  SPO  department.  Graphics  software 
contain  tools  for  drawing,  charting,  designing,  making 
presentations,  and  producing  various  combinations  of  these 
tasks.  Today,  graphics  programs  are  directed  at  specific 
tasks  like  charting  complex  data  for  trend  analysis  or 
creating  color  slides  to  enhance  a  visual  presentation 
(73:126).  However,  this  is  not  the  way  it  used  to  be.  In 
the  not  so  distant  past,  the  art  or  reprographics  depart¬ 
ments  controlled  this  area  which  meant  managers  were  at  the 
mercy  of  these  departments  for  assistance  and  therefore  had 
to  adhere  to  their  time  and  personnel  constraints.  However, 
the  emergence  of  the  PC  and  graphics  software  have  given  the 
manager  more  flexibility  to  manage  this  required  capability. 
This  does  not  mean  art  departments  are  obsolete;  on  the 
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contrary,  these  departments  will  always  have  more  and  better 
equipment  and  more  experienced  personnel.  However,  now 
managers  need  not  wait  on  art  departments  to  fulfill  routine 
requirements.  And  they  should  not  since  "about  70  percent 
of  all  graphics  created  by  art  departments  are  nothing  more 
than  word  charts,"  according  to  Jim  Meade  of  Personal 
Computing  magazine.  By  creating  word  and  other  simple 
charts  themselves,  users  have  the  advantage  of  being  able  to 
give  more  thought  to  their  ideas  and  can  make  last  minute 
changes  with  a  minimum  of  inconvenience  (65:55).  This  is 
especially  important  considering  the  long  lead-time 
typically  required  by  graphics  departments.  Moreover,  users 
can  make  sure  the  charts  are  accurate  if  they  do  them 
themselves.  Meade  provides  the  following  general  rule  to 
follow:  "When  content  matters  most,  users  should  generate 

their  own  charts.  When  appearance  takes  precedence,  turn  to 
the  art  department."  He  further  points  out  that,  generally, 
presentations  made  in-house  do  not  require  the  level  of 
quality  as  that  needed  for  presentations  outside  the 
organization  (65:55). 

Deciding  upon  a  PC  graphics  software  is  not  as  difficult 
as  some  analysts  believe,  if  the  user  is  trying  to  choose 
the  top-rated  program.  Clearly,  the  top-rated  graphics 
program  is  Software  Publishing's  Harvard  Graphics  (52:128; 


131 


89:134).  However,  there  are  a  number  of  other  choices 
including  Micrografx's  Graph  Plus  and  Lotus'  Freelance  Plus 
(52:128-129) . 

Freelance  Plus  (Version  3.0)  at  $495,  provides  "fill-in- 
the-blank"  wor)csheets  in  which  the  user  enters  data  and  then 
selects  a  chart  option.  The  method  produces  very  handsome 
presentation-quality  graphics.  The  program  boasts  a 
straightforward  user  interface  and  an  ample  context- 
sensitive  help  menu.  Freelance  Plus  3.0  consists  of  three 
modules:  1)  Charts  and  Drawings  to  produce  and  improve 

charts;  2)  Portfolio,  an  organization  utility  which  lists  up 
to  100  files  by  topic,  file  path,  and  name,  with  the  ability 
to  print  them  in  batch  mode;  and  3)  Screen  Show  for 
developing  on-screen  slide  shows  with  a  number  of  transition 
effects  lilce  slow  fades  and  overlay  techniques  (54:139-141). 

Graph  Plus  ($495)  is  a  PC  Magazine  "Best  Product  of 
1988"  award  winner  (11:130).  This  sophisticated  program 
operates  under  Microsoft  Windows  and  is  better  suited  for 
the  experienced  graphics  user  since  it  is  not  the  easiest  of 
programs  to  master.  However,  it  does  provide  excellent 
integration  capability  with  other  applications  (especially 
spreadsheets)  and  is  compatible  with  a  wide  range  of 
printers  and  plotters  (52:128;  75:143-145). 

The  industry  leader.  Harvard  Graphics  (Version  2.1)  at 
$495,  has  earned  the  "Top  Rated"  award  from  Personal 
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Computing  and  the  "Editor’s  Choice"  award  from  PC  Magazine 
(76:145;  89:134).  This  presentation  graphics  program 
incorporates  "an  uncommon  combination  of  simplicity  and 
depth."  It  offers  an  abundance  of  features  like  macros; 
batch  printing;  customization  using  drawing  functions, 
symbols,  and  color  and  patterns;  importing  and  exporting 
data  files  of  other  applications;  support  for  a  host  of 
printers  and  plotters;  a  Screenshow  utility  for  incor¬ 
porating  special  effects  in  desktop  presentations;  and 
commendable  documentation.  But,  perhaps  Harvard  Graphics' 
biggest  plus  is  its  ease  of  use.  This  program  is  ideal  for 
the  manager  who  does  not  have  the  time  or  inclination  to 
experiment  with  different  packages  in  search  of  the  one  that 
works  best  for  him/her  (76:145-149) . 
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Appendix  C:  Strategies  for  Assisting  Information 
Reguirements  Determination 

Renowned  MIS  author,  Gordon  Davis  outlined  four 
strategies  for  aiding  the  determination  of  information 
requirements.  A  brief  discussion  of  these  strategies  is 
presented  below. 

The  asking  directly  strategy  tasks  the  analyst  to 
obtain  information  requirements  directly  from  the  persons 
who  will  be  using  the  application  by  simply  asking  them  what 
their  requirements  are.  This  concept  assumes  the  users  are 
able  to  appropriately  define  and  limit  their  problem  areas 
and  overcome  any  biases  due  to  small  sample  size,  recency  of 
the  requirement,  unused  data,  and  concreteness  of  the 
perceived  requirement  (24:13-14).  This  strategy  is  most 
useful  when  the  requirement  is  well-defined  or  established 
by  law,  legislation,  or  other  authority.  The  use  of  closed 
questions,  open  questions,  brainstorming,  guided 
brainstorming,  and  group  consensus  are  the  diverse  methods 
for  employing  an  asking  strategy  (25:481). 

The  concept  of  deriving  from  an  existing  information 
system  may  be  used  when  the  existing  system  has  an 
operational  history  from  which  requirements  can  be  derived 
for  a  similar  kind  of  organization  or  application.  Davis 
lists  four  types  of  existing  information  systems  which  are 
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useful  for  deriving  future  system/application  requirements. 
They  are: 

1.  An  existing  system  being  replaced  by  a  new 
system , 

2.  An  existing  system  in  another,  similar 
organization , 

3.  A  proprietary  system  or  package,  and 

4.  Descriptions  in  textbooks,  handbooks, 
industry  studies,  etc.  (25:482) 

Since  information  systems  generally  provide  information 
services  to  facilitate  operation  by  those  that  utilize  the 
information  (object  systems),  the  requirements,  therefore, 
originate  from  the  activities  of  those  object  systems. 
Consequently,  Davis  suggests  the  most  logical  and  complete 
way  to  determine  those  requirements  is  to  study  the 
characteristics  of  the  object  or  utilizing  system.  This 
synthesis  from  characteristics  of  the  utilizing  system 
approach  is  believed  valid  when  the  utilizing  system  is 
changed  or  the  proposed  system  is  different  from  the 
existing  system  (in  content,  form,  complexity,  etc.)  so  that 
basing  requirements  on  the  existing  system  will  not  provide 
a  complete  and  accurate  set  of  requirements  (24:14).  Davis 
lists  eight  general  methods  for  implementing  a  requirements 
determination  strategy.  They  are  briefly  described  below. 

1.  Normative  Analysis  -  This  method  is  based  on  the 
fundamental  similarities  between  classes  of  utilizing 
system.  It  says,  given  a  generic  set  of  requirements 
associated  with  a  general  application  (i.e.,  accounting, 
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inventory  control,  etc.),  the  analysis  centers  on  tailoring 
the  basic  set  of  requirements  to  a  specific  organization  or 
application  (24:15-16).  However,  it  is  primarily  applicable 
at  the  organizational  level  (i.e.,  for  determining 
organization-wide  requirements)  [25:483]. 

2.  Strategy  Set  Transformation  (SST)  -  This  approach, 
developed  by  W.  R.  King,  describes  organizational  infor¬ 
mation  requirements  from  the  basic  mission,  objectives, 
strategies,  and  other  strategic  variables  of  the  organi¬ 
zation.  This  method  is  designed  predominately  for  the 
organization  level  (51:27-30). 

3.  Critical  Factors  Analysis  -  Information 
requirements  are  derived  from  a  set  of  factors  managers  view 
as  critical  to  the  successful  operation  and  management  of 
the  organization  (24:16-17).  A  good  example  of  this  method 
is  the  Critical  Success  Factors  (CSF)  method  developed  by 

J.  F.  Roclcart.  Using  CSF,  analysts  solicit  users  to  define 
those  factors  which  are  essential  for  success  in  performance 
of  their  duties  or  decision  making.  A  small  group  of 
critical  factors  usually  emerge  from  which  requirements  can 
be  derived  (83:81-93).  This  technique  may  be  used  at  either 
the  organization  or  application  (i.e.,  for  specific  depart¬ 
ment  task  requirements)  level  (25:485). 

4.  Process  Analysis  -  This  approach  concentrates  on 
the  notion  that  business  processes  (collection  of  activities 
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and  decisions  necessary  to  manage  organizational  resources) 
are  the  basis  for  information  system  support.  Since 
processes,  assumedly,  remain  constant  over  time,  the 
requirements  derived  from  these  processes  reflect  the 
constant  needs  of  the  organization  (24:17).  It  is  most 
applicable  for  organizational  requirements  determination 
(25:485).  A  good  example  of  this  method  is  Business  Systems 
Planning  (BSP).  This  IBM  developed  technique  allows 
information  requirements  to  be  derived  from  the  utilizing 
system  in  a  top-down  fashion  by  first  identifying  the 
business  objectives  and  then  defining  the  business  processes 
to  develop  a  proposed  information  architecture  (20). 

5.  Ends-Means  Analysis  -  This  technique  separates  the 
definition  of  ends  or  outputs  (goods,  services,  and  infor¬ 
mation)  from  the  means  (inputs  and  processes)  generated  by 
an  organizational  process.  The  ends  or  outputs  from  one 
process  is  used  as  the  input  for  another  process.  For 
instance,  the  inventory  process  may  provide  raw  materials  to 
the  production  process.  Managers  are  first  asJced  to  define 
the  ends  and  means  for  their  respective  offices,  followed  by 
the  measurements  for  effectiveness  and  efficiency.  This 
method  has  been  used  in  many  industrial  settings  and  is  more 
tailored  to  defining  organizational  requirements 
(25:485-486) . 
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6.  Decision  Analysis  -  This  approach  has  proven  very 
useful  in  determining  information  requirements  where  the 
decision  process  is  fairly  well  defined.  The  basic  process 
has  three  steps:  1)  identify  the  decision  to  be  made,  2) 
define  the  decision  algorithm  or  process,  and  3)  describe 
the  information  required  for  the  decision  process  (24:17). 
For  unstructured  decisions,  this  method  does  not  seem  any 
more  effective  than  the  others.  It  is  primarily  designed 
for  specific  application-level  requirements  (25:486-487). 

7.  Socio-Technical  Analysis  -  This  technique  is  based 
on  the  philosophy  that  organizational  behavior  problems  are 
the  principle  cause  of  information  system  failures  (14:17). 
It  consists  of  two  parts:  social  analysis  and  technical 
analysis.  The  social  analysis  considers  the  social,  human 
interaction  aspects  of  the  organization  in  determining 
requirements;  whereas,  the  technical  analysis  talces  into 
account  design  analysis  and  feedback  systems  which  require 
information  (24:18).  The  general  approach  has  three  phases 
1)  a  strategic  design  process  (formulation  of  project  goals 
and  objectives),  2)  a  socio-technical  system  design  process 
(emphasizes  design  procedures  and  the  social  change 
process),  and  3)  an  ongoing  management  process  (continual 
fine-tuning  of  the  system  implementation)  [14:17].  This 
approach  is  appropriate  for  applications  involving  many 
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users,  or  where  the  application  will  greatly  impact  the  work 
environment,  social  interaction,  or  job  design  (25:487). 

8.  Input-Process-Output  Analysis  -  This  systems 
approach  to  requirements  determination  begins  with  a  top- 
down  design  of  a  utilizing  system  concentrating  on  the 
inputs,  outputs,  and  transformation  process.  Subsystems  of 
the  utilizing  system  are  analyzed  to  subdivide  them  into 
smaller  subsystems  until  information  processing  activities 
can  be  defined  as  separate  activities  within  a  subsystem. 

The  advantage  of  this  form  of  analysis  is  that  it  is  both 
systematic  and  comprehensive.  "By  starting  at  a  high  level 
and  factoring  into  subsystems,  there  is  reasonable  assurance 
of  completeness."  The  analysis  can  be  taken  to  as  low  a 
level  of  detail  as  necessary.  The  data  flow  diagram  is  an 
excellent  example  of  this  method.  The  Structured  Analysis 
and  Design  Technique  (SADT)  is  a  requirements  determination 
methodology  based  on  this  systems  approach  (25:487-488).  It 
will  be  discussed  later  in  this  chapter. 

Most  traditional  methods  for  determining  information 
requirements  are  intended  to  provide  a  complete  and  accurate 
set  of  requirements  prior  to  designing  and  building  the 
actual  information  system.  However,  many  times  these 
traditional  methods  will  not  be  possible  due  to  the  lack  of 
an  existing  model  on  which  to  base  requirements.  As  a 
result,  another  approach  to  requirements  determination  is  to 
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start  with  a  general  set  of  "best  guess"  requirements  and 
implement  an  information  system  to  reflect  those  require¬ 
ments.  This  approach  is  called  discovering  from  experi¬ 
mentation  with  an  evolving  information  system.  This  initial 
system  should  be  designed  for  easy  change  because  as  users 
make  use  of  the  system,  they  will  inevitably  have  additional 
requirement  requests.  After  establishing  a  workable  system, 
the  user  and  analyst  can  work  together  iterating  the  system 
design  until  it  fits  the  users'  needs.  This  strategy  has 
been  often  referred  to  as  prototyping  or  heuristic 
development  (25:488,568). 
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Appendix  D :  Description  of  Common  Requirements 
Determination  Methodologies 

This  appendix  supplies  a  brief  description  of  some 
common  methodologies  used  to  assist  information  requirements 
determination  within  organizations. 

Data  Flow  Analysis.  This  methodology  employs  a 
pictorial  representation  of  the  flow  of  data  in  carrying  out 
specific  office  functions.  The  data  flow  diagrams  use  just 
four  symbols  to  show  how  all  essential  parts  of  the 
investigated  information  system  fit  together  (88:112).  The 
idea  is  to  furnish  a  top-down  structure  of  the  logical 
system  design  by  "moving  from  lesser  to  greater  levels  of 
detail  that  contribute  to  the  design  process"  (62:143).  In 
this  way,  analysts  and  users  may  better  define  the  steps  in 
the  flow  of  information  and  the  decision-making  process 
(62:141-143).  The  steps  in  data  flow  analysis  are  as  listed 
below: 

1.  Study  the  office  operations  and  ongoing 
processes . 

2.  Identify  how  data  is  processed  in  handling 
transactions  and  completing  tasks. 

3.  Follow  the  flow  of  data  from  input  to 
processing  to  storage  to  retrieval  to 
output . 

4.  Gradually  add  details  at  lower  levels. 

(88 : 112) 
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The  advantages  of  this  methodology  are  two-fold.  First, 
it  is  simple  to  apply  which  means  it  is  easy  to  get  users 
involved  in  the  requirements  determination  process.  Second, 
it  allows  the  analyst  to  concentrate  on  areas  of  interest  to 
find  better  ways  of  performing  a  particular  task 
(88:114-115) . 

Structured  Analysis  and  Design  Technique  (SADT) .  This 
proprietary  system  for  requirements  determination  is  devised 
to  "force  structure  on  the  unstructured  systems  analysis  and 
design  task"  (62:140).  It  is  unique  in  that  it  incorporates 
techniques  for  performing  both  systems  analysis  and  design, 
as  well  as  management  practices  to  apply  these  techniques 
which  can  substantially  increase  the  productivity  of  an 
^/lalyst  team  (47:1-1).  SADT  is  composed  of  a  graphic 
language  for  model  building,  a  method  for  model  development, 
and  management  practices  for  controlling  the  system/- 
application  development  (62:140). 

With  the  aid  of  the  graphic  modeling  language,  SADT 
attempts  to  guide  the  analysts  into  a  top-down  decomposition 
of  the  problem  (62:140).  It  uses  a  d’agramming  technique 
which  subdivides  information  processes  into  activities 
(actigrams)  and  data  flow  (datagrams).  SADT  uses  the 
following  functional  phases  of  analysis: 

1.  Diagramming  activities  and  data  aspects 
pertaining  to  the  system. 
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2.  Cross-referencing  of  activity  and  data 
diagrams . 

3.  Additional  activity  and  data  diagramming 
and  cross-referencing,  as  needed,  to 
complete  the  functional  analysis. 

4.  Analyzing  the  sequence  of  activities. 

5.  Identifying  mechanisms  which  will 
implement  the  functions  and  act  as  a 
bridge  to  the  design  phase.  (47:3-2) 

Although  SADT  is  an  enhancement  of  data  flow  analysis 
(allowing  teams  to  work  and  interact  as  one  to  solve  complex 
information  problems  [84:161]),  it  is  not  an  easily  applied 
methodology.  It  requires  a  number  of  resources  in  terms  of 
people  (normally  four  to  six  analysts  and  support  personnel) 
and  time  (usually  ranging  from  six  to  nine  months) .  In 
addition,  SADT  does  not  integrate  users  into  the  process 
very  well  (62:140-141)  . 

The  two  requirements  determination  methodologies 
previously  discussed,  represent  relatively  opposite  ends  of 
the  spectrum  with  regards  to  complexity  and  the  amount  of 
resources  demanded.  The  three  methodologies  which  follow 
are  considered  more  moderate  approaches  to  requirements 
determination . 

Cognitive  Mapping.  This  methodology  is  designed  to 
isolate  bottlenecks  in  the  flow  of  information  to  assist 
analysts  and  users  in  focusing  on  those  tasks  which  are 
deemed  most  critical  to  the  organization.  It  is  described 
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as  a  mental  method  of  representing  the  relationships  between 
functions  or  tasks  which  are  perceived  to  exist  and  the 
examination  of  these  relationships  empirically  to  determine 
whether  they  truly  do  exist  (67:45-47).  Cognitive  mapping 
is  comprised  by  the  following  eight  steps: 

1.  Identification  of  the  user  set  and 
interfacing  organization. 

2.  Identification  of  decision  areas. 

3.  Definition  of  decision  areas. 

4.  Development  of  a  descriptive  model  of  the 
system. 

5.  Development  of  a  normative  model  of  the 
system . 

6.  Development  of  a  consensus  model  of  the 
system. 

7.  Decision  model  identification  and 
specification. 

8.  Specification  of  the  information 
requirements.  (67:45-46) 

This  methodology  is  believed  to  yield  excellent  results 
in  very  unstructured  office  environments.  It  enables  users 
to  determine  those  tasks  which  are  most  important  for 
completion  of  their  daily  projects  (67:45-53). 

Critical  Task  Method  (CTM) .  This  methodology  was 
developed  to  determine  users’  office  computer  needs.  It 
assumes  the  users  (knowledge  workers)  are  best  equipped, 
rather  than  the  systems  analysts,  to  understand  and  identify 
the  critical  bottlenecks  (tasks  that  limit  or  prevent  user 
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efficiency  and  effectiveness)  in  an  unstructured  office 
environment.  CTM  begins  by  determining  what  tasks  managers 
perform  to  accomplish  their  duties,  and  it  uses  the  idea  of 
task  descriptors  to  define  these  various  management 
responsibilities  (45:293-295).  Below  is  a  brief  description 
of  the  five  steps  in  the  Critical  Task  Method. 

1.  Interview  a  subset  of  the  knowledge  workers.  This 
is  done  to  determine  what  jobs  managers  perform  and 
how  they  do  them. 

2.  Develop  a  profile  of  task  descriptors.  This  gives 
a  breakdown  of  maintenance  and  cognitive  tasks. 
Maintenance  tasks  are  routine  duties  which  do  not 
directly  produce  a  product  (e.g.,  doing 
calculations,  typing,  filing,  etc.);  whereas, 
cognitive  tasks  are  higher  level  mental  operations 
which  produce  an  end  product  like  reports  or  forms. 

3.  Develop  a  profile  of  the  support  modes.  This  is 
just  a  listing  of  the  various  modes  of  support  the 
managers  use  to  assist  their  duties. 

4 .  Validate  the  profile  of  task  descriptors  and 
support  modes.  This  listing  is  reviewed  for 
accuracy,  clarity,  and  completeness,  and  to  make 
any  necessary  additions  or  modifications. 

5.  Survey  the  hold-out  sample.  The  remaining 

knowledge  workers  are  given  the  completed  listing 
of  CTM  task  descriptors  and  support  modes  to 
determine  the  critical  bottleneck  tasks. 
Participants  are  then  asked  to  choose  the  critical 
cognitive  tasks  necessary  to  fully  define  their 
work  bottlenecks.  They  are  also  asked  to  provide 
,,p  ’"odes  of  surr'oi't  they  presently  use  to 

overcome  the  bottlenecks  (45:294-295). 

Information  Systems  Requirements  Analysis  (ISRA) .  This 
stepwise  methodology  (developed  by  the  Air  Force)  helps 
organizations  identify  ways  to  improve  their  mission 
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effectiveness  by  enhancing  information  management  systems 
which,  in  turn,  help  decrease  mission  support  costs  and 
increase  the  probability  for  mission  success.  It  is 
designed  for  use  by  either  individual  offices  or  entire 
organizations  (29:1)  and  consists  of  the  following  11  steps: 

1.  Selection  of  managers  to  participate  in  the 
analysis  based  on  personnel  who  are  under  their 
immediate  supervision. 

2 . ’  Identification  of  the  unit's  operational  mission. 

3.  Preparation  of  a  list  (by  each  participating 
manager)  of  the  responsibilities  assigned  to  the 
manager's  section  or  branch,  including  wartime  and 
additional  duties. 

4.  Preparation  of  an  Analysis  Worksheet  (AF  Form  3231) 
for  each  responsibility  identified  in  Step  3. 

5.  Analysis  of  the  information  recorded  on  the 
Analysis  Worksheets  to  identify  requirements  which 
will  achieve  the  objectives:  1)  increase  the 
probability  of  operational  mission  success  or  2) 
decrease  the  cost  of  mission  support. 

a.  First,  identify  requirements  which  can  be 
satisfied  by  implementing  procedural  changes. 

b.  Second,  identify  requirements  that  cannot  be 
satisfied  by  making  procedural  changes. 

6.  Recording  requirements  on  the  Requirements  and 
Justification  Worksheet  (AF  Form  3230). 

7.  Completion  of  the  Information  Systems  Requirement 
Document  (ISRD)  lAW  AFR  700-3.  The  ISRD  specifies 
the  required  capability,  justifies  the  need, 
identifies  available  resources,  and  serves  as  the 
validation  and  approval  document  for  that  need. 

8.  Submission  of  the  ISRD  to  the  Information  Systems 
Review  Board  (ISRB)  for  review  and  validation  of 
properly  justified  requirements  lAW  AFR  700-5. 
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9.  Implementation  of  information  technology  or 

procedural  changes  based  on  the  ISRB  validated 
requirements . 

10.  Evaluation  of  the  implemented  information 
technology  or  procedural  changes  to  ensure 
objectives  have  been  met. 

11.  Reporting  of  evaluation  findings  back  to  the  ISRB 
(29:4-34) . 

Th“  ISRA  method  provides  the  basis  for  a  very  thorough 
requirements  determination  analysis;  however,  it  entails  an 
arduous  and  time-consuming  process.  In  interviews  with 
various  AFSC  SPO  managers,  this  method  has  been  doomed  to 
failure  due  to  the  tremendous  time  and  effort  required  to 
implement  this  process.  Various  AFSC  base  communications- 
computer  systems  officers  (CSOs)  echo  these  sentiments  when 
they  convey  that  organizations  are  discouraged  from  pursuing 
this  approach  to  requirements  determination  when  they  learn 
the  amount  of  time  and  energy  involved  to  satisfy  a 
requirement . 
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Append! >!  E:  Sample  Survey  Cover  Letter  Addressed  to 

Deputy  SPO  Directors 


DEPARTMENT  OF  THE  AIR  FORCE 
AIR  UNIVERSITY 

AIR  FORCE  INSTITUTE  OF  TECHNOLOGY 
WRIGHT-PATTERSON  AIR  FORCE  BASE  OH  45433-6583 


REPLy  TO 

ATTNOF;  (Capt  R 1  c H 3 T d s oo/ L S A/ AV  785-5''jr'i 

SUBJECT;  gpQ  Personal  Computer  (PC)  Software  Requirements  Model 
Development  Survey  (USAF  Survey  Control  No.  89-37) 

Selected  SPO  Director  s/ Program  Managers  Within  AFSC 

1.  Please  take  the  time  to  distribute  three  of  these  question¬ 
naires  to  each  of  your  functional  departments  for  completion. 
They  should  be  returned  in  the  envelopes  provided  by  9  Jun  89. 

2.  The  survey  examines  how  your  SPO  identifies  PC  software 
requirements,  how  the  software  is  procured,  and  how  the  develop- 
m.ent  of  a  tailored  software  acquisition  model  for  SPOs  might 
simplify  the  software  procurement  process.  The  data  gathered 
will  be  used  as  part  of  an  AFIT  research  project,  and  may 
potentially  improve  the  software  acquisition  process. 

3.  For  each  set  of  three  questionnaires  distributed  to  your 
functional  managers,  please  have  one  completed  by  at  least  a 
branch  chief  (or  equivalent)  and  the  remaining  two  by  personnel 
in  ranks  below  the  branch  chief  level.  This  is  important  to 
obtain  a  cross-section  of  personnel  who  use  PC  software  and  who 
identify  software  requirements. 

4.  Personnel  surveyed  may  be  military  and/or  civilian.  Their 
responses  will  be  combined  with  others  and  will  not  be  personal 
attributed  to  them  or  to  your  SPO. 

5.  Your  participation  in  this  research  effort  is  completely 
voluntary,  but  your  assis-tance  is  certainly  appreciated. 

Any  questions  concerning  this  survey  should  be  directed  to 
Lt  Col  D.  J.  McBride,  AFIT/LSY,  AUTOVON  785-4845. 


^HN  DUMOND,  Lt  Col,  USAF  2  Atch 

Read,  Department  of  System  1.  30  Questionnaires 

Acquisition  Management  2.  30  Return  Envelopes 

School  of  Systems  and  Logistics 


STRENGTH  THROUGH  KNOWLEDGE 


Appendi)^  F:  Sample  Survey  Cover  Letter 
Addressed  to  Participants 

DEPARTMENT  OF  THE  AIR  FORCE 
AIR  university 

AIR  FORCE  INSTITUTE  OF  TECHNOLOGY 
WRIGHT-PATTEHSON  AIR  FORCE  BASE  OH  45433-6583 


?Ano°  CCapt  Richardson/LSA/AV  785-5435) 

SUBJECT  SPO  Personal  Computer  (PC)  Software  Requirements  Model 
Development  Survey  Package 

All  Participants 

1 .  Please  take  the  time  to  complete  the  attached  survey  and 
return  it  in  the  envelope  provided  by  9  Jun  89. 

2.  The  Department  of  Defense,  functioning  in  an  era  of  continued 
manpower  cuts,  coupled  with  a  management  philosophy  of  ‘doing 
more  with  less,"  has  prompted  the  Air  Force  to  acquire  PCs  as  an 
office  automation  technique  to  increase  office  or od uc t i v i ty . 
Perhaps  nowhere  is  the  value  of  the  highest  possible  office 
productivity  greater  than  in  SPOs  ,  where  timely,  organized,  and 
accurate  information  is  essential  to  the  success  of  an  acquisi¬ 
tion  program.  PCs,  as  relatively  inexpensive,  yet  sophisticated 
office  management  tools,  require  various  application  software 
packages  to  efficiently  and  effectively  automate  office  tasks. 

But  with  the  abundance  of  PC  software  tools  on  the  market, 
choosing  the  right  software  for  the  right  job  can  be  a  difficult 
proposition.  The  problem  is  there  are  no  comprehensive  criteria 
for  assisting  SPOs  in  determining  their  PC  software  requirements. 

3.  Your  assistance  in  this  study  will  help  to  identify  what  PC 
software  applications  SPOs  currently  use,  how  PC  software  require¬ 
ments  are  identified,  what  PC  software  acquisition  processes  are 
used,  how  effective  the  current  acquisition  processes  are,  and 
whether  an  alternative  PC  software  requirements  model  for  SPOs 
might  be  beneficial.  The  data  gathered  will  be  used  in  support  of 
an  AFIT  research  project,  and  may  potentially  improve  the  current 
PC  software  acquisition  process. 

4.  Participation  is  completely  voluntary.  Your  responses  will  be 
combined  with  others  and  will  not  be  attributed  to  you  persoj.ally 
or  to  your  SPO . 

5.  Thank  you  for  your  assistance  in  this  research  effort.  If  you 
have  questions  regarding  this  survey,  please  contact  Lt  Col  D.  J. 
McBride  (AFIT/LSY)  at  AUTOVON  785-4845. 


DUMOND  ,  Lt  Oo  1  ,  USAF 
Head,  Department  of  System 
Acquisition  Management 
School  of  Systems  and  Logistics 

1  4'^/ 


2  Atch 

1.  Questionnaire 

2.  Return  envelope 


Appendix  G;  Sample  Survey  Instructions 


INSTRUCTIONS  FOR  COMPLETING  SPO  PC  SOFTWARE 
REQUIREMENTS  MODEL  SURVEY 


The  attached  survey  is  designed  to  gather  information  in  the 
following  areas  of  SPO  PC  software  requirements  determination; 

1.  How  effective  and  efficient  is  your  department's  use 
of  PC  software? 

2.  How  are  PC  software  requirements  determined  for  your 
department? 

3.  How  effective  is  your  department's  current  process  in 
determining  PC  software  requirements? 

4.  Is  there  an  alternative  process  better  suited  to 
identify  these  software  requirements? 

The  survey  will  take  about  25  minutes  to  complete  and 
consists  of  a  variety  of  multiple  choice,  dichotomous,  rating 
scale,  and  open-ended  questions.  For  each  multiple  choice, 
dichotomous,  and  rating  scale  question,  please  circle  the  letter 
or  range  corresponding  to  your  selected  answer.  Some  of  the 
multiple  choice,  dichotomous,  and  rating  scale  questions  also  ask 
for  a  brief  explanation,  depending  upon  your  response.  In 
addition,  a  few  open-ended  c[uestions  have  been  incorporated  to 
give  greater  ffeedom  of  response.  Your  opinions  and  constructive 
criticism  of  the  current  process  for  determining  PC  software 
requirements  are  important.  Please  write  legibly  to  be  sure  we 
include  your  opinions  in  the  analysis. 

Finally,  when  you  have  completed  the  questionnaire,  please 
return  it  in  the  preaddresed  envelope.  Your  cooperation  is 
greatly  appreciated. 
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Appendix  H 


!  !=^ample  SPQ  PC  Software  Requ  i  reme.n_ts 
Mo,de_l . Survey 

USAF  Survey  Control  No.  33-37  (Expires  31  Oct  89) 

SYSTEM  PROGRAM  OFFICE  (SPO)  PC  SOFTWARE 
REQUIREMENTS  MODEL  SURVEY 


THIS  FIRST  SECTION  OF  QUESTIONS  (QUESTIONS  1  THROUGH  5)  IDENTIFIES 
WHAT  YOUR  JOB  IS  AND  WHAT  DUTIES  YOU  PERFORM  TO  ACCOMPLISH  THAT  JOB. 

: .  What  is  your  current  i ob  title /position? 


2 .  What  is  your  present  grade  or  rank? 


3 .  In  which  SPO  functional  department  are  you  currently  working? 
(circle  letter) 

a.  Project/Program  Management  g.  Test  Management 

b.  Engineering  h.  Contract  Management 

c.  Manufacturing/Quality  Assurance  i.  Data  Management 

d.  Logistics  j.  Procurement 

e.  Configuration  Management  k.  Other  (specify) 

f.  Program  Control  _ 

4.  What  is  your  primary  job  responsibil_cy  within  your  department? 
Briefly  explain. 


5.  What  are  the  top  two  sped  f ic  duties  you  perform  to  accomplish 
this  primary  responsibility?  Briefly  explain. 

(Example:  Develop  and  write  methods  of  test  for  inclusion  in  the 

Test  &  Evaluation  Master  Plan  (TEMP) ) 


1. 


Ibl 


QUESTIONS  6  THROUGH  14  ADDRESS  YOUR  USE  OF  GOVERNMENT-OWNED  OFFIOE 
PC  SOFTWARE  IN  THE  ACCOMPLISHMENT  OF  YOUR  DUTIES, 


6.  Have  either  of  the  specific  duties,  identified  in  Question  5, 
been  supported  using  PC  software?  (circle) 

a.  Yes,  both  duties 

b.  Yes,  one  of  the  duties  (circle  the  number  corresponding  to 

the  supported  duty:  1  2  ) 

c.  No,  neither  duty 

7.  Could  a  specific  duty  (identified  in  Question  5)  which  is  cur¬ 
rently  unsupported  be  supported  using  PC  software?  (circle) 

a.  Not  Applicable,  both  duties  are  currently  supported 

b.  Yes,  both  duties  could  be  supported 

c.  Yes,  one  of  the  duties  (circle  the  number  corresponding  to 

to  the  unsupported  duty:  1  2  ) 

d .  No 

e.  Do  Not  Know 

(If  you  do  not  currently  use  any  PC  software  applications  to  support 
your  job,  please  skip  to  Question  19.) 

8.  What  PC  software  applications  do  you  use  for  your  job?  (Circle  all 
applicable.)  Then  for  each  application  selected,  approximate  the 
number  of  hours  per  week  you  use  the  application.  (Circle  the 
appropriate  range  of  hours.) 


AddI ications 

Hours 

Used 

Per 

Week 

a . 

Spreadsheets 

(Ex:  LOTUS  1-2-3,  jUATTRO, 

etc .  ) 

< 

2 

2-5 

5-8 

8-10 

> 

10 

b . 

Word  processors 
(Ex:  WORDSTAR,  PEAChTEXT, 

etc . ) 

< 

2 

2-5 

5-8 

8-10 

> 

10 

c . 

Graphics  packages 

(Ex:  HARVARD  GRAPHICS,  CHART,  etc.) 

< 

2 

2-5 

5-8 

8-10 

> 

10 

d. 

Prograjuming  language  i 
(Ex:  BASIC,  FORTRAN,  etc.) 

< 

2 

2-5 

5-8 

8-10 

> 

10 

e . 

Decision  support  systems 

(Ex;  EXPERT  CHOICE,  DECISION  AID,  etc.) 

< 

2 

2-5 

5-8 

8-10 

> 

10 

f  . 

Statistical  packages 

(Ex;  BASS,  POWERPACK,  etc. 

) 

< 

2 

2-5 

5-8 

8-10 

10 

g- 

Program  management 

(Ex;  CAPPS,  EXPERT  SYSTEM, 

etc .  ) 

< 

2 

2  -5 

5-8 

8-10 

> 

10 

h. 

Database  management 

(Ex;  DBASE,  CONDOR,  etc.) 

< 

2 

2-5 

5-8 

8-10 

> 

10 

i . 

Integrated  packages 

(Ex:  ABILITY,  ENABLE,  etc. 

multiple  applications) 

which  combine 

< 

2 

2-5 

5-8 

8-10 

> 

10 

j  • 

Others 

< 

2 

2-5 

5-8 

8-10 

> 

10 

(specify) 


Question  9  addresses  the  acquisition  method  used  to  obtain  the  applica¬ 
tions  used  for  your  job.  In  answering  this  question,  please  refer  to 
the  following  list  of  acquisition  methods. 

1.  Standard  small  computer  contract 

2.  Sole  source  or  special  purchase  action 

3.  Contract  negotiated  by  Small  Computer  Technical  Center  (SCTC) 

4 .  Self-purchase 

5 .  Other 

6 .  Do  not  know 


9.  For  each  PC  software  application  used,  which  acquisition  method 
was  used?  (Circle  the  appropriate  corresponding  number.) 


PC  Software  Appl ication 


Accaiisition  Method 


Spreadsheet 

(If  "Other,"  specify 


b.  Word  processor 

(If  "Other,"  specify 

c.  Graphics  package 

(If  "Other,"  specify 


d.  Programming  language 
(If  "Other,"  specify 


e . 


f . 


Decision  support  system 
(If  "Other,"  specify 


Statistical  package 
(If  "Other,"  specify 


g.  Program  management 
(If  "Other,"  specify 

h.  Database  management 
(If  "Other,"  specify 


Integrated  package 
(If  "Other,"  specify 

Other  (specify) 


(If  "Other, 


specify 


10.  From  the  software  inventory  listed  below,  circle  the  letters 
corresponding  to  the  specifically  named  products  you  use 
(lAW  the  applications  selected  in  Question  8),  and  indicate 
for  each  whether  you  were  involved  in  the  procurement  process  for 
that  software. 


SOFTWARE  INVENTORY 


Spreadsheets  Involved?  C Yes/No) 

a.  LOTUS  1-2-3 

b .  PEACHCALC 

C .  PERFECT  CALC 

d .  QUATTRO 

e .  SUPERCALC 

f.  VP  PLANNER 

g.  Other  _ 


Word 

Processors  Involved?  ( Yes/No'> 

a.  MICROSOFT  WORD 

b .  MULTIMATE 
C.  PC  WRITE 

d.  PEACHTEXT 

e .  VOLKSWRITER 

f.  WORDPERFECT 

g.  WORDSTAR 

h.  WRITE  ONE 

i.  WRITESOFT 

j .  Other  _ 


Database 

Management  Involved?  (Yes/No) 

a.  CONDOR 

b.  DBASE 

C.  DATAEASE 

d.  HOMEBASE 

e.  MICRON 

f .  PARTS  MASTER 

g.  PC  FILE 

h.  Q&A 

i .  Other 


Graphics  Involved?  f Yes/No) 

a.  CAD-3 D 

b .  CHART 

C .  GRAFTALK 

d.  HARVARD  GRAPHICS 

e .  SHOWMAKER 

f.  STATGRAPHICS 

g.  Other  _ 


Integrated 

Systems  Involved?  ( Yes/No) 

a.  ABILITY 

b.  ENABLE 

c.  Other 


Decision  Support 

Systems  Involved?  (Yes/No) 

a.  EXPERT  CHOICE 

b.  DECISION  AID 

c.  Other 


Program 

Management  Involved?  f Yes/No) 

a.  EXPERT  SYSTEM 

b .  HARVARD  TOTAL 
PROJECT  MANAGER 

c.  PERT 

d.  PMSS  (CAPPS,  CEM,  etc.) 

e.  SUPER  PROJECT 
EXPERT 

f.  TIMELINE 

g.  Other  _ 


(List  continues  on  next  page.) 
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a.  BASS  a. 

b .  MATHCAD  b . 

c.  MICROSTAT  c. 

d .  POWERPACK  d . 

e.  QBS  e. 

f.  Other  _  f- 


Other 


Involved?  ( Yes/No) 


j  • 

k. 

l. 


ASSEMBLER 

BASIC 

C 

C-86 
COBOL 
FORTRAN 
GW  BASIC 
MS  FORTRAN 
PASCAL 

TURBO  PASCAL 

Z-BASIC 

Other 


For  Question  11,  please  refer  to  the  following  task  list. 

a.  Authoring  e.  Organizing/Scheduling 

b.  Decision-making  f.  Planning 

c.  Diagnosis/Problem  solving  g.  Presentations  (briefs) 

d.  Monitoring/Controlling  h.  Other  (please  specify) 


11.  For  each  PC  software  product  specified  in  Question  10,  provide 

the  generic  task  (using  the  letter(s)  corresponding  to  the  task(s) 
listed  above)  and  a  brief  specific  description  of  the  task(s) 
it  is  used  for. 


Product  Name 


Task  Description 


(Example:  DBASE 


d.  Monitor/control  configuration  item  changes) 


12.  For  each  PC  software  product  identified  in  Question  11,  which 
has  satisfactorily  supported  a  task,  briefly  explain  why 
you  are  satisfied  with  it. 

Product  Name  Primary  Reason  I s^  For  Satisfaction 

(Example:  Chart  Flexibility  in  changing  fonts  and  sizes  to 

appeal  to  different  audiences) 


13.  For  each  PC  software  product  identified  in  Question  11,  which 
has  not  satisfactorily  supported  a  task,  briefly  explain 
why  you  are  dissatisfied  with  it. 

Product  Name  Primary  Reason ( s^  For  Dissatisfaction 

(Example:  Expert  Choice  Does  not  allow  enough  knowledge  leyels 

to  support  a  thorough  rationale  for 
making  a  source  selection  decision 
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Based  on  your  knowledge  and  experience,  which  two  software 
products  are  the  most  useful  to  you?  (Rank  order  by 
product  name  from  list  in  Question  11.) 


THIS  NEXT  GROUP  OF  QUESTIONS  (QUESTIONS  15  THROUGH  18)  ADDRESSES 
YOUR  USE  OF  PERSONAL  PC  SOFTWARE  TO  SUPPORT  YOUR  JOB  DUTIES. 


15.  Have  you  used  (at  work  or  at  home)  your  own  personal  PC 
software  to  accomplish  work-related  tasks?  (circle) 

a .  Yes 

b .  No 

(If  you  answered  "No"  to  Question  15,  please  skip  to  Question  19.) 


16.  Please  list  the  product  naine(s)  of  the  personal  software  used. 
( Example :  QUATTRO ) 


17.  Why  were  these  tasks  done  using  personal  (non-government)  PC 
software?  (circle) 

a.  Personal  preference  for  an  alternative  software  product 

b.  Required  software  not  available  or  not  available  in 
sufficient  quantity 

c.  Work  at  home  requires  compatible  software 

d.  Other  (explain) _ _ _ 


10  . 

How  often  is  this  personal 
office  work?  (circle) 

software  used 

for  your  government 

a.  Daily  d. 

b.  Almost  daily  e. 

c.  Weekly  f. 

Bi-weekly 

Monthly 

Quarterly 

g.  Other  (specify) 

THIS  FINAL  SECTION  OF  QUESTIONS  DEALS  WITH  THE  WAY  YOUR  DEPARTMENT 
ACQUIRES  PC  SOFTWARE. 


19.  Is  there  a  department  policy  (formal  or  informal)  establishing  a 

process  or  method  to  determine  PC  software  requirements?  (circle) 

a .  Yes 

b .  No 

c.  '  1  Not  Know 

(If  you  answered  "No"  or  "Do  Not  Know,"  to  Question  19,  you  have 
completed  the  survey.  THANK  YOU  FOR  YOUR  PARTICIPATION. ) 


20. 


What  source (s)  of  guidance  do  you  use  when  outlining  PC 
software  purchase  requirements?  (Circle  all  applicable.) 


a . 

Magazines 

f . 

Other  users 

b. 

AFR  700-3 

g- 

Vendors 

c . 

AFR  700-26 

h. 

Communication  units 

d. 

AFP  700-30 

i . 

Other  (specify) 

e . 

Small  Computer 

Technical  Center  (SCTC) 

j  • 

None 

21.  Is  the  person  who  defines  your  PC  software  requirements  a 
•designated  computer  resources  representative?  (circle) 

a .  Yes 

b.  No  (Please  specify  this  individual's  position.)  _ 


c.  Do  Not  Know 


22.  Briefly  describe  the  process  your  department  uses  to  determine 
PC  software  purchase  requirements. 


23  . 


How  effective  is  this  PC  software  procurement  process  in  providing 
the  correct  or  requested  software?  (circle) 


a.  Highly  effective 

b.  Moderately  effective 

c.  Neither  effective  nor  ineffective 

d.  Somewhat  ineffective 

e.  Very  ineffective 


1  so 


24.  If  you  answered  "d."  or  "e."  to  Question  23,  briefly  comment 
on  the  reason (s)  for  ineffectiveness. 


25.  How  responsive  (timely)  is  this  procurement  process  in 
providing  the  correct  or  requested  software?  (circle) 

a.  Extremely  responsive 

b.  Very  responsive 

c.  Moderately  responsive 

d.  Somewhat  responsive 

e.  Not  at  all  responsive 

26.  If  you  answered  "d."  or  "e."  to  Question  25,  briefly  comment 
on  the  reason (s)  for  unresponsiveness. 


27.  Can  you  suggest  an  alternative  process  or  ways  to  improve  the 
current  process  of  acquiring  PC  software?  Please  explain. 


THIS  COMPLETES  THE  SURVEY.  THANK  YOU  FOR  YOUR  ASSISTANCE . 
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Appendix  I :  Comments/Suaaestions  of  Survey  Participants 
for  Improving  the  PC  Software  Procurement  Process 


Comments/Suggestions 


1.  Four  participants  said  designated  computer  representa¬ 
tives  should  be  used  to  ask  users  what  PC  software  they 
want  and  then  recommend  those  products  the  SPO  can 
afford. 

2.  One  participant  advocated  just  buying  all  of  the 
products  on  the  Standard  Small  Computer  Contract. 

3.  Four  respondents  suggested  computer  users  define  their 
own  needs,  discuss  the  available  known  software,  and 
then  decide  on  the  best  available  and  purchase  it. 

4.  Two  individuals  remarked  users  should  establish  their 
own  requirements  and  submit  a  request  to  the  CSRB. 

5.  One  respondent  said  computers  should  be  bought/ issued 
with  operating  systems  resident.  Then  allow  users  to 
request  specific  software  to  support  requirements. 

6.  Three  participants  suggested  mandating  one  word 
processor  for  Air  Force  and  DoD-wide  use. 

7.  Two  respondents  proposed  using  a  base  software 
organization  that  stocks  required  software  for  immediate 
delivery. 


Alternate  Requirements  Determination  Processes 


1.  (a)  Increase  visibility  of  the  software  requirements 

focal  point. 

(b)  Address  user  needs  by  tailoring  requirements  to 
satisfy  office  tasks. 

(c)  Provide  more  training. 


(d)  Supply  a  listing  of  available  software  to  allow 
users  to  choose  from. 
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2.  (a)  Set  aside  a  budget  for  software. 

(b)  Don't  be  concerned  with  word  processing  consistency 
within  the  SPO,  just  buy  good,  inexpensive 
conversion  software  utilities  which  will  allow 
everyone  to  use  what  they  are  comfortable  with. 

(c)  Allow  users  to  define  their  own  requirements,  and 
then  submit  requests  to  the  SPO  director  for 
approval  and  purchase. 


3.  (a)  Department  computer  representatives  should  interview 

department  personnel  to  identify  needs. 

(b)  Obtain  a  list  of  requirements. 

(c)  Have  SPO  computer  representatives  consolidate 
department  needs  with  the  rest  of  the  SPO. 

(d)  SPO  representatives  should  confirm  requirements  with 
department  representatives  to  assure  consolidated 
requirements  are  valid. 

(e)  SPO  representatives  submit  requests  to  the  CSRB. 


4.  (a)  Have-  a  committee  of  educated  computer  software 

personnel  solicit  requirements  from  SPO  department 
personnel . 

(b)  Conduct  a  series  of  studies  to  determine  department 
current  and  future  PC  software  requirements. 

(c)  Procure  software  inline  with  study  findings. 

(d)  Provide  adequate  training  support  for  initial  and 
upgraded  software  purchases. 
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